Systems and methods for work capacity planning

ABSTRACT

Methods, apparatuses, and systems for scheduling tasks to field professionals include: receiving a set of requests reflecting demand for on-site services, wherein the set of requests is associated with a number of task types; receiving availability data indicative of an availability of a plurality of field professionals to perform on-site services; receiving skills data indicative of capabilities of each of the plurality of field professionals with respect to the task types; obtaining at least one desired scheduling weight for the number of task types; generating a schedule for the plurality of field professionals based on the demand for on-site services, the availability data, and the skills data; and wherein generating the schedule for the plurality of field professionals includes including a first task in the schedule when the first task conforms with the at least one desired scheduling weight and excluding a second task from the schedule when the second task does not conform with the at least one desired scheduling weight.

CROSS REFERENCES TO RELATED APPLICATIONS

This application claims the benefit of priority of U.S. ProvisionalPatent Application No. 62/785,423, filed on Dec. 27, 2018; and U.S.Provisional Patent Application No. 62/871,397, filed Jul. 8, 2019. Allof the foregoing applications are incorporated herein by reference intheir entirety.

BACKGROUND I. Technical Field

The present disclosure relates generally to the field of managingservice organizations. More specifically, the present disclosure relatesto systems, methods, and devices for providing services such as servicesprovided by professionals or experts in the field.

II. Background Information

One aspect of process management involves matching available resourcesto the tasks to be performed by or within an organization. In theservice providers industry, for example, the main resources are theservice professionals (such as field technicians, help desk or customerservice operators, insurance assessors, business consultants, etc.) andtheir available work hours. Other resources may include vehicles, toolsand equipment, spare parts, office space (e.g., meeting rooms), etc. Theservice tasks are usually initiated by customer requests, and typicallycannot be precisely predicted on the micro-level, as there is no way toknow when a customer will call and request assistance.

Service providers thus face the challenge of accurately managing thesize, mix of skills, and regional allocation of their resources. Erringby allocating too few resources results in failing to meet customerexpectations, risking losing customers, and sometimes requiring theservice organization to pay contract-specified penalties. Erring byallocating too many resources results in spending excessive money onresources that are not fully utilized. Optimizing the schedule of taskscan increase productivity and revenue for the service provider.

The disclosed embodiments are directed to providing new and improvedways for scheduling tasks to field professionals that overcome problemsand inefficiencies in existing systems.

SUMMARY

Consistent with disclosed embodiments, systems, methods, and computerreadable media enable scheduling tasks to field professionals based onreal-time conditions. For example, consistent with one aspect adisclosed system includes a network interface and a processorconnectable to the network interface. The processor determines real-timeschedule information for a set of field professionals independent fromany schedule update received from the field professionals via thenetwork interface. The processor also determines, from the real-timeschedule information associated with a first field professional,existence of a delay associated with one or more tasks assigned to thefirst field professional. The processor further determines a likelihoodthat the delay will interfere with the first field professional arrivingto an identified location associated with an assigned task at ascheduled time, and determines from real-time schedule informationassociated with a second field professional whether the second fieldprofessional can arrive to the identified location associated with thetask assigned to the first field professional at the scheduled time.Thereafter, the processor reassigns the task assigned to the first fieldprofessional based on the real-time schedule information associated withthe first field professional and the real-time schedule informationassociated with the second field professional. The processor alsoprovides to at least one of the first field professional and the secondfield professional, using the network interface, information reflectingthe reassignment of the task.

In another aspect, an additional system for scheduling tasks to fieldprofessionals based on real-time conditions is provided. The systemincludes a network interface and a processor connectable to the networkinterface. The processor is configured to: receive, from the networkinterface, progress information for a set of field professionals;determine a delay associated with one or more tasks assigned to a firstfield professional; determine a likelihood that the delay will interferewith the first field professional arriving to an identified locationassociated with an assigned task at a scheduled time; reassign theassigned task to a second field professional based on the determinedlikelihood that the delay will interfere with the first fieldprofessional arriving to the identified location associated with theassigned task at the scheduled time; and provide the second fieldprofessional, using the network interface, information reflecting thereassignment.

Consistent with disclosed embodiments, systems, methods, and computerreadable media enable scheduling tasks to field professionals. Forexample, consistent with one aspect a disclosed system includes anetwork interface and a processor connectable to the network interface.The processor receives a set of requests reflecting demand for on-siteservices, wherein the set of requests is associated with a number oftask types. The processor also receives availability data indicative ofan availability of a plurality of field professionals to perform on-siteservices and skills data indicative of capabilities of each of theplurality of field professionals with respect to the task types. Theprocessor further obtains at least one desired scheduling weight for thenumber of task types, and generates a schedule for the plurality offield professionals based on the demand for on-site services, theavailability data, and the skills data. In one embodiment, generatingthe schedule for the plurality of field professionals comprisesincluding a first task in the schedule when the first task conforms withthe at least one desired scheduling weight and excluding a second taskfrom the schedule when the second task does not conform with the atleast one desired scheduling weight.

In another aspect, a method for scheduling tasks to field professionalsis provided. The method includes: receiving a set of requests reflectingdemand for on-site services, wherein the set of requests is associatedwith a number of task types; receiving availability data indicative ofan availability of a plurality of field professionals to perform on-siteservices; receiving skills data indicative of capabilities of each ofthe plurality of field professionals with respect to the task types;obtaining at least one desired scheduling weight for the number of tasktypes; generating a schedule for the plurality of field professionalsbased on the demand for on-site services, the availability data, and theskills data; and wherein generating the schedule for the plurality offield professionals comprises including a first task in the schedulewhen the first task conforms with the at least one desired schedulingweight and excluding a second task from the schedule when the secondtask does not conform with the at least one desired scheduling weight.

Consistent with disclosed embodiments, systems, methods, and computerreadable media enable using predicted demand to optimize taskscheduling. For example, consistent with one aspect a disclosed systemincludes a memory configured to store historical data associated withpast demand for field professionals, a network interface, and aprocessor connectable to the network interface. The processor isreceives a set of requests reflecting a current demand for on-siteservices, predicts imminent demand for on-site services based on thehistorical data, generates a schedule for a set of field professionalsbased on the current demand for on-site services, and reserves in theschedule availability based on the predicted imminent demand for on-siteservices.

In another aspect, an additional system for using predicted demand tooptimize task scheduling is provided. The system includes a memoryconfigured to store historical data associated with past demand forfield professionals, a network interface, and a processor connectable tothe network interface. The processor receives a set of requests foron-site service, wherein the set of requests are associated with anumber of task types and each request is associated with a differentlocation. The processor also uses the historical data to identifyservice zones in the geographical area associated with predicted demandfor specific task types. The processor further determines, based on therequests, a set of daily schedules of tasks for a set of fieldprofessionals, and, for a certain daily schedule with a task associatedwith a location in proximity to an identified service zone, reservecapacity to account for predicted demand. Thereafter, the processorprovides, using the network interface, directional instructions to afield professional assigned to the certain daily schedule to a locationin proximity to a service zone.

Consistent with disclosed embodiments, systems, methods, and computerreadable media enable scheduling technical services to be completed in asingle visit. For example, consistent with one aspect a method includes:storing in a database a plurality of records reflecting characteristicsassociated with completing a set of technical services, whereininformation in each record is derived from historical experience ofcompleting each of the technical services; receiving a request for a newtechnical service associated with a location; and assigning a fieldprofessional to perform the new service having determined frominformation in the database a likelihood that the field professionalwill complete the new technical service in a single on-site visit at thelocation.

In another aspect, an additional system for scheduling technicalservices to be completed in a single visit is provided. The systemincludes a memory configured to store information including details ofpreviously completed tasks, a network interface, and a processorconnectable to the network interface. The processor receives a requestfor an on-site service at a selected location. The processor alsoidentifies a set of attributes associated with the requested on-siteservice; and uses the stored information and the set of attributes toidentify at least one requirement for completing the on-site service ina single visit. The processor further assigns a field professional to atask of providing the on-site service, wherein the assignment satisfiesthe identified at least one requirement. Thereafter, the processor mayprovide, using the network interface, information for directing thefield professional to the selected location.

Consistent with disclosed embodiments, systems, methods, and computerreadable media enable identifying causes for unscheduled tasks. Forexample, consistent with one aspect a disclosed system includes anetwork interface, a memory, and a processor connectable to the networkinterface. The memory is configured to store details of previouslyreceived requests for services. The processor receives, from the networkinterface, a set of requests for services; and schedule a set of tasksbased on scheduling constraints, wherein each task is expected to becompleted within a period of time from when a corresponding request wasreceived. The processor also determines a common cause why at least tworequests were not scheduled with tasks expected to be completed withinthe period of time, wherein the common cause is associated with at leastone of the scheduling constraints; and enable reducing the number offuture unscheduled tasks based on the determination.

In another aspect, an additional system for identifying causes forunscheduled tasks is provided. The system includes system that mayinclude a network interface, a memory, and a processor connectable tothe network interface. The memory is configured to store details ofpreviously received requests for services. The processor may beconfigured to access the memory and to receive, from the networkinterface, a set of requests for services; schedule a set of tasks basedon scheduling constraints. If the number of requests that were notscheduled with tasks expected to be completed within the period of timeis greater than a predetermined threshold, the system may initiate anaction, such as issuing a warning or automatically changing a schedulingconstraint.

Consistent with disclosed embodiments, systems, methods, and computerreadable media enable task scheduling for location-based andlocation-agnostic tasks. For example, consistent with one aspect adisclosed system includes a memory, network interface, and a processorconnectable to the network interface. The processor receives a set offirst requests for on-site assistance from a first set of users andreceives a set of second requests for remote assistance from a secondset of users. After receiving the first and second sets of requests, theprocessor assigns a plurality of location-based tasks associated withfirst requests to one or more field professional. The processor may thenreceive real-time information associated with the one or more fieldprofessional including current location and determine based on thereal-time information whether the one or more field professional cancomplete a location-agnostic task associated with a second request aftercompleting a first location-based task and before starting a secondlocation-based task. Subsequently, the processor assigns thelocation-agnostic task to the one or more field professional.

In another aspect, an additional system for scheduling forlocation-based and location-agnostic tasks is provided. The systemincludes a memory, network interface, and a processor connectable to thenetwork interface. The processor receives an urgency level of alocation-agnostic task associated with a second request and to obtaininformation identifying one or more field professional as more suitableto provide the location-agnostic task than one or more second fieldprofessional. The information may consist of skills data, pastexperience, and ranking. After assigning the location-agnostic task, theprocessor instructs the one or more field professional to initiate thelocation-agnostic task before or after driving to a location associatedwith a location-based task.

Consistent with disclosed embodiments, systems, methods, and computerreadable media enable a multi-route process for appointment booking. Forexample, consistent with one aspect a disclosed system includes amemory, network interface, and a processor connectable to the networkinterface. The processor receives a request to book a new appointmentfor a service. After receiving the request, the processor outputs afirst booking response for the request, wherein the first bookingresponse is determined using a multi-route model. The multi-route modelis configured to determine booking responses in different ways. Theprocessor verifies the first booking response based on a second bookingresponse determined using the multi-route model.

In another aspect, an additional system for enabling a multi-routeprocess for appointment booking is provided. The system includes amemory, network interface, and a processor connectable to the networkinterface. The processor receives a user refusal of a first offeredappointment time. The processor then contacts the user and offers afirst alternative appointment time determined by a first schedulingmodel, or a second alternative appointment time determined by a secondschedule model. The processor may also be configured to attempt tochange an existing assignment of a field professional to meet the firstproposed time.

Consistent with disclosed embodiments, systems, methods, and computerreadable media enable the scheduling of tasks to field professionals.For example, consistent with one aspect a disclosed method includesreceiving a request to book a new appointment for a service, the servicebeing expected to be completed within a time period; identifying a firstpossible time slot and a subsequent second possible time slot for thenew appointment within the time period; calculating a first schedulingcost associated with the first possible time slot and a secondscheduling cost associated with the second possible time slot andenabling selection of the second possible time slot when it isdetermined that both the first scheduling cost and the second schedulingcost are below a scheduling cost threshold; and outputting ano-available-time-slot notification when is determined that both thefirst scheduling cost and the second scheduling cost are above thescheduling cost threshold.

In another aspect, a system for scheduling of tasks to fieldprofessionals is provided. The system includes a network interface, amemory, and a processor connectable to the network interface. Theprocessor estimates driving durations necessary to conduct anappointment. The processor also offers a proposed time associated with asecond possible time slot later than the first possible time slot if thesecond driving duration is smaller than the first driving duration. Theprocessor may also be configured to output a no-available-time-slotnotification if the first driving duration and the second drivingduration are greater than a driving duration threshold.

Consistent with disclosed embodiments, systems, methods, and computerreadable media enable the scheduling of tasks for field professionalsbased on users' profile. For example, consistent with one aspect adisclosed system includes a network interface, a memory, and a processorconnectable to the network interface. The processor receives a requestfrom a user for an on-site service. The processor also identifies a setof possible time slots for providing the on-site service based on aschedule of a set of field professionals. Additionally, the processorretrieves information indicative of an availability of the user toaccept the on-site service. The processor also determines a subset ofpossible time slots for providing the on-site service based on theretrieved information indicative of an availability of the user.Further, the processor may propose a time for providing the on-siteservice based on a time slot selected form the subset of possible timeslots.

In another aspect, an additional system for scheduling of tasks forfield professionals based on users' profile is provided. The systemincludes a network interface, a memory, and a processor connectable tothe network interface. The processor receives from a user a request fora service. The processor also identifies a first possible time slot forproviding the service associated with a first field professional and asecond possible time slot later than the first possible time slot,wherein the second possible time slot is associated with a second fieldprofessional. The processor may also retrieve information indicative ofthe availability of the user to accept the service, Finally, theprocessor proposes a time associated with the second possible time slotlater than the first possible time slot when the retrieved informationsuggests that the user will not be able to accept the service during thefirst time slot.

Consistent with disclosed embodiments, systems, methods, and computerreadable media enable the scheduling of appointments from the customer'slocation. For example, consistent with one aspect a disclosed systemincludes a network interface, a memory, and a processor connectable tothe network interface. The processor receives a request from a user foran on-site service associated with a location. Information reflecting anassignment is transmitted to a field professional. While the fieldprofessional is at the location, the field professional may, using amobile device for example, send an indication that an additional visitis required to complete the on-site service. After receiving theindication, a schedule of the field professional is accessed to identifyan available time slot in the future. A proposed time for the additionalvisit associated with the identified time slot is then provided.

In another aspect, a system for scheduling of additional appointmentswhen a user declines a first time slot. The system includes a networkinterface, a memory, and a processor connectable to the networkinterface. The processor receives a request from a user for an on-siteservice associated with a location and identify a plurality of availabletime slots. If, after the plurality of available time slots are providedto the user, the user does not select one of the plurality of availabletime slots, additional information is retrieved indicative of anavailability of the user. A subset of the plurality of time slots isdetermined based on the availability of the user. This subset is thenprovided to the user.

Consistent with disclosed embodiments, systems, methods, and computerreadable media enable assigning a field professional to performadditional service based on customer feedback. For example, consistentwith one aspect a disclosed system includes a network interface, amemory, and a processor connectable to the network interface. Theprocessor receives a request from a user for an on-site serviceassociated with a location. At least one field professional is assignedto at least one task of providing the at least one on-site service atthe location. After the service is performed, data is obtainedassociated with the service, including user feedback. If another requestis received from the user for an additional service associated, theprocessor retrieves information including data associated with theearlier service from memory. A field professional is then assigned toperform the additional service based on the retrieved information.

In another aspect, a system for assigning a field professional toperform additional service based on data associated with a priorservice. The system includes a network interface, a memory, and aprocessor connectable to the network interface. The processor isconfigured to receive data associated with a service. The data mayinclude recorded interactions between an employee and a user, feedbackfrom a user after service is performed, metadata indicating service timeassociated with a field professional, social network posts by a user,and data from field professionals. The data may then be evaluated todetermine a level of satisfaction.

Consistent with disclosed embodiments, systems, methods, and computerreadable media enabling updating a scheduling engine that schedulestasks to field professionals. For example, consistent with one aspect adisclosed system includes at least one memory configured to store dataassociated with an optimization engine, a network interface, and aprocessor. The processor periodically receives from a remote server dataassociated with a native scheduling engine. Then, the processorprocesses in a stateless manner the data received periodically from theremote server using the optimization engine to update a predictionmodel. Thereafter, the processor transmits information associated withthe updated prediction model to the remote server for enablingimprovement of the native scheduling engine.

Consistent with disclosed embodiments, systems, methods, and computerreadable media enabling scheduling tasks to field professionals using aremote optimization engine are disclosed. For example, consistent withone aspect a disclosed system includes at least one memory configured tostore data associated with scheduled tasks, a network interface, and aprocessor. The processor receives a plurality of requests for on-siteservice from a plurality of users, wherein the requests are associatedwith a plurality of locations. The processor also schedules a set oftasks from the plurality of requests using a native scheduling engine.Then, the processor updates the native scheduling engine based oninformation received from a remote server, and uses the nativescheduling engine on the previously scheduled set of tasks to identify atask scheduled in an unoptimized manner. Thereafter, the processorcauses a schedule change associated with the identified task.

Consistent with disclosed embodiments, systems, methods, andcomputer-readable media enable assigning tasks based on real-timeconditions. For example, consistent with one aspect a disclosed systemincludes a network interface and a processor. The processor provides afield professional with information about a daily schedule of assignedtasks associated with a set of requests for on-site services. Theprocessor also receives real-time information reflecting a likelihoodthe field professional will complete the daily schedule of assignedtasks. The processor may determine, from the real-time information,existence of an unplanned event likely to interfere with the fieldprofessional completing at least one task from the daily schedule.Thereafter, the processor also presents a plurality of optional tasks tothe field professional based on the determination. Upon detecting aselection of one of the plurality of optional tasks, the processorassigns the field professional to the selected task and unassign the atleast one task.

Consistent with disclosed embodiments, systems, methods, andcomputer-readable media enable assigning tasks based on real-timeconditions. For example, consistent with one aspect a disclosed systemincludes memory configured to store historical data associated withassignments of tasks for a plurality of field professionals when windowsof opportunity are identified, a network interface, and a processor. Theprocessor receives a set of requests for on-site service from aplurality of users, wherein each request is associated with a differentlocation. The processor also receives real-time information about aprogress of a field professional assigned to a set of tasks associatedwith a subset of requests. The processor may dynamically determine awindow of opportunity to assign an additional task to the fieldprofessional and may identify a plurality of optional tasks that thefield professional is determined to be able to complete during thewindow of opportunity. Thereafter, the processor automatically selectsone of the optional tasks for assignment to the field professional basedon the historical data; and assigns the field professional to theselected task.

Consistent with disclosed embodiments, systems, methods, and computerreadable media enabling scheduling services to customers and connecteddevices. For example, consistent with one aspect a disclosed systemincludes a processor connectable to a network interface. The processorreceives a first request for an on-site service; the first requestincludes information identifying a location associated with a customer.The processor also schedules a task associated with the first request tobe performed by a field professional on a first scheduled date. Afterscheduling the task associated with the first request, for example, theprocessor may receive a second request from a connected device for anon-site service. The second request may have an associated urgency leveldetermined from information received from the connected device. Theprocessor may further determine a time period that corresponds with theassociated urgency level of the on-site service for the connected deviceand schedule a task associated with the second request to be performedby the field professional or another field profession on a secondscheduled date based on the associated urgency level. The firstscheduled date and the second scheduled date may be the same date ordifferent dates. The processor may also receive confirmation that thetask associated with the first request and the task associated with thesecond request have been completed.

In another aspect, an additional system for scheduling services tocustomers and connected devices is provided. The system includes anetwork interface and a processor connectable to the network interface.The processor receives a first request for an on-site service; the firstrequest includes information identifying a location associated with acustomer. The processor schedules a task associated with the firstrequest to be performed by a field professional on a first scheduleddate. The processor may also receive a second request from a connecteddevice for an on-site service at a second location in proximity to thefirst location. The on-site service for the connected device may have anassociated urgency level. The processor may determine a time period thatcorresponds with the associated urgency level of the on-site service forthe connected device, and determine, based on the time period, that theon-site service for the connected device can be scheduled at the certaindate. Thereafter, the processor assigns a single field professional toprovide the on-site services in the first location and in the secondlocation at the certain date.

Consistent with disclosed embodiments, systems, methods, and computerreadable media enabling scheduling parts delivery. For example,consistent with one aspect a disclosed system includes a networkinterface and a processor connectable to the network interface. Theprocessor receives a set of requests for on-site services, wherein theon-site services of at least some of the requests require parts, forexample replacement parts. The processor also assigns a set of taskscorresponding with the set of requests to a field professional. Inaddition, the processor determines a set of parts the field professionalis likely to require to complete the assigned set of tasks, anddetermines that the field professional needs an additional part notcurrently in the field professional's inventory to complete the set oftasks. Thereafter, the processor may schedule a task for delivery in thefield of the at least one additional part to the field professional.

In another aspect, an additional system for scheduling parts delivery isprovided. The system includes a network interface and a processorconnectable to the network interface. The processor receives a set ofrequests for on-site services, wherein the on-site services of at leastsome of the requests require parts. The processor further schedules aset of tasks corresponding with the set of requests to a fieldprofessional. The processor may also provide data indicative of expectedparts that the field professional would need for completion of the setof tasks. In addition, the processor receives from the fieldprofessional, while the field professional is at a location associatedwith a current task, a request for at least one additional part.Thereafter, the processor schedules a task for delivery in the field ofthe requested at least one additional part to the field professional.

Consistent with other disclosed embodiments, non-transitorycomputer-readable storage media may store program instructions, whichare executed by at least one processing device and perform any of themethods described herein.

The foregoing general description and the following detailed descriptionare exemplary and explanatory only and are not restrictive of theclaims.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this disclosure, illustrate various disclosed embodiments. Inthe drawings:

FIG. 1 is a schematic illustration of an example system for schedulingtasks to field professionals, consistent with the present disclosure;

FIG. 2 is a block diagram that illustrates some of the components thesystem of FIG. 1, consistent with the present disclosure;

FIG. 3A and FIG. 3B are schematic maps used to illustrate an example ofthe daily schedule of tasks of two field professionals, consistent withthe present disclosure;

FIG. 4 is a schematic illustration of an example system, consistent withthe present disclosure;

FIG. 5 is a schematic illustration of an example logical architecturalmodel for implementing embodiments of the present disclosure;

FIG. 6A is a flowchart of an example process for task scheduling basedon real-time conditions, consistent with the present disclosure;

FIG. 6B is a diagram of example planned and actual schedules of fieldprofessionals, consistent with the present disclosure;

FIG. 7A is a flowchart of an example process for scheduling tasks tofield professionals according to desired scheduling weights, consistentwith the present disclosure;

FIG. 7B is a flowchart of another example process for scheduling tasksto field professionals according to desired scheduling weights,consistent with the present disclosure;

FIG. 7C is a diagram of an example schedule for several fieldprofessionals, consistent with the present disclosure;

FIG. 8A is a flowchart of an example process for scheduling tasks tofield professionals based on predicted demand, consistent with thepresent disclosure;

FIG. 8B is a diagram of a timeline reflecting an example scheduleassociated with tasks, consistent with the present disclosure;

FIG. 8C is a diagram of a map showing example service zones associatedwith on-site services, consistent with the present disclosure;

FIG. 8D and FIG. 8E are flowcharts of another example processes forscheduling tasks to field professionals based on predicted demand,consistent with the present disclosure;

FIG. 9A is a flowchart of an example process for scheduling technicalservices to field professionals to be completed in a single visit,consistent with the present disclosure;

FIG. 9B is a flowchart of another example process for schedulingtechnical services to field professionals to be completed in a singlevisit, consistent with the present disclosure;

FIG. 10 is a diagram that illustrates a scheduling engine that receivesrequests, applies constraints, and schedules tasks, consistent with thepresent disclosure;

FIG. 11 is a flowchart showing an exemplary process for reducing thenumber of future unscheduled tasks, consistent with the presentdisclosure;

FIG. 12 is a flowchart showing a process for scheduling tasks andinitiating an action based on the number of unscheduled tasks,consistent with the present disclosure;

FIG. 13 is a flowchart showing an exemplary process for assigninglocation-agnostic task to one or more field professionals, consistentwith the present disclosure;

FIG. 14 is a diagram showing a planned field professional schedulemodified by observed traffic delays, consistent with the presentdisclosure;

FIG. 15A and FIG. 15B are diagrams showing assignment of alocation-agnostic task and reassignment of an additional location-basedtask between field professionals, consistent with the presentdisclosure;

FIG. 16 is a flowchart showing an exemplary process for a multi-routemodel for appointment booking, consistent with the present disclosure;

FIG. 17A and FIG. 17B show an example flowchart for determining bookingresponses and initiating actions in response, consistent with thepresent disclosure;

FIG. 18 is a flowchart showing another exemplary process for amulti-route model for appointment booking, consistent with the presentdisclosure;

FIG. 19A and FIG. 19B show an example flowchart for offering appointmenttimes to a user, consistent with the present disclosure;

FIG. 20 is a flowchart showing an exemplary process for offering timesfor service based on system considerations, consistent with the presentdisclosure;

FIG. 21 is a flowchart showing an exemplary process for offering timesfor service based on driving duration, consistent with the presentdisclosure;

FIG. 22 is a flowchart showing an exemplary process for providing a usera proposed time associated with the second possible time slot or a firstpossible time slot, consistent with the present disclosure;

FIG. 23 is a flowchart showing an exemplary process for offering timesfor service based on user availability, consistent with the presentdisclosure;

FIG. 24 is a flowchart for checking user availability information andupdating a proposed time, consistent with the present disclosure;

FIG. 25 is a flowchart showing an exemplary process for providing a useralternative possible time slot, consistent with the present disclosure;

FIG. 26 is a flowchart showing an exemplary process for offering timesfor an additional visit to a location, consistent with the presentdisclosure;

FIG. 27 is a flowchart for providing proposed time slots based oninformation indicative of an availability of a user, consistent with thepresent disclosure;

FIG. 28 is a flowchart showing an exemplary process for assigning afield professional to perform additional services after performing atleast one on-site service, consistent with the present disclosure;

FIG. 29 is a diagram showing types of data associated with a serviceprovided by a field professional, consistent with the presentdisclosure;

FIG. 30 is a flowchart for assigning a field professional based onsatisfaction level and availability of the user, consistent with thepresent disclosure;

FIG. 31 is a flowchart for suggesting and accepting a suggestion for afield professional, consistent with the present disclosure;

FIG. 32 is a bar graph showing a typical task duration distribution,consistent with the present disclosure;

FIG. 33 is a schematic illustration of a scheduling system that includesa central server and local servers, consistent with the presentdisclosure;

FIG. 34 is a message flow diagram showing example messages exchangedbetween different elements of the scheduling system of FIG. 33;

FIG. 35 is a diagram showing two schedules of field professionalsscheduled using different versions of scheduling engines, consistentwith the present disclosure.

FIG. 36 is a flowchart showing an exemplary process for changing theschedule, consistent with the present disclosure;

FIG. 37 is a flowchart showing an exemplary process for updating anative scheduling engine of a local server, consistent with the presentdisclosure;

FIG. 38 is a flowchart showing an exemplary process for scheduling tasksusing a data from a central server, consistent with the presentdisclosure;

FIG. 39A and FIG. 39B are diagrams showing of planned timelines of afield professional and actual timelines of the field professional,consistent with the present disclosure;

FIG. 40A and FIG. 40B are schematic diagram showing two graphical userinterfaces for a field professional, consistent with the presentdisclosure;

FIG. 41 is a is a block chart illustrating an exemplary embodiment of amemory containing software modules, consistent with the presentdisclosure;

FIG. 42 is a flowchart showing a first exemplary process for assigningtasks based on real-time information, consistent with the presentdisclosure;

FIG. 43 is a flowchart showing a second exemplary process for assigningtasks based on real-time information, consistent with the presentdisclosure;

FIG. 44 is a timeline showing an exemplary process for schedulingon-site services to connected devices, consistent with the presentdisclosure;

FIG. 45 is a schematic map showing locations of scheduled on-siteservices for connected devices and locations of scheduled on-siteservices for human customers, consistent with the present disclosure;

FIG. 46 is a flowchart showing an exemplary process for schedulingon-site services for connected devices and human customers, consistentwith the present disclosure;

FIG. 47 is a diagram showing a field professional's usage of partsthroughout a workday, consistent with the present disclosure;

FIG. 48 is a schematic map showing possible parts delivery points alonga travel path of a field professional, consistent with the presentdisclosure;

FIG. 49A is a flowchart showing an exemplary process for schedulingparts delivery, consistent with a disclosed embodiment; and

FIG. 49B is a flowchart showing another exemplary process for schedulingparts delivery, consistent with a disclosed embodiment.

DETAILED DESCRIPTION Introduction

The following detailed description refers to the accompanying drawings.Wherever possible, the same reference numbers are used in the drawingsand the following description to refer to the same or similar parts.While several illustrative embodiments are described herein,modifications, adaptations and other implementations are possible. Forexample, substitutions, additions, or modifications may be made to thecomponents illustrated in the drawings, and the illustrative methodsdescribed herein may be modified by substituting, reordering, removing,or adding steps to the disclosed methods. Accordingly, the followingdetailed description is not limited to the disclosed embodiments andexamples. Instead, the proper scope is defined by the appended claims.

The present disclosure is directed to systems and methods fordistributing resources in the field, including professionals, engineers,agents, and the like. The term “field professional” refers, for example,to a trained and/or qualified individual who provides services (often,expert) at a location or worksite. For example, in the home utilitiesindustry, field professionals may be certified technicians who aretrained to install, replace, or repair electrical equipment. In thetelecommunications and cable industry, field professionals may beindividuals who install cable or run telephone lines into residences orbusiness establishments. In heavy engineering, mining, industrial andmanufacturing, field professionals may be individuals who are dispatchedfor preventative maintenance and repair. In property maintenance, fieldprofessionals may be individuals who are dispatched for landscaping,irrigation, and home and office cleaning. In the HVAC industry, fieldprofessionals may be individuals who have the expertise and equipment toinvestigate units in residential, commercial and industrialenvironments. In healthcare, field professionals may be individuals whoprovide in-home care for elderly or disabled. In gas utilities, fieldprofessionals may be individuals who are dispatched to investigate andrepair suspected leaks. As used herein, the term “and/or” refers to andencompasses any and all possible combinations of one or more of theassociated listed items, as well as the lack of combinations wheninterpreted in the alternative (“or”).

In embodiments consistent with this disclosure, systems and methods areused to schedule tasks to one or more field professionals. The term“scheduling tasks” is used herein to refer, for example, to a processfor determining an order (e.g., chronological order) for a set of tasksa field professional performs. The tasks may be associated withrequested services and require a field professional to travel todifferent locations. There are different types of scheduled tasks, forexample, installing, replacing, or repairing objects, and each task typemay require a different skill set. In addition, some scheduled tasks maybe location-based tasks that require the field professional to visit acustomer's location, for example, business or residence, and some tasksmay be location-agnostic tasks that do not require the fieldprofessional to visit a customer's location. Location-agnostic tasks maybe viewed as support sessions that a technician can perform remote fromthe customer place.

A system consistent with the present disclosure is configured to managea number of field professionals (e.g., more than 50 field professionals,more than 250 field professionals, more than 750 field professionals),and the term “scheduling tasks” may also include selecting which fieldprofessional will be assigned to each task. In some embodiments,scheduling tasks may include generating a daily schedule for each fieldprofessional.

In one embodiment, the system may receive one or more requests fortechnical services. The term “request” includes, for example, anindication that a service (for example, a technical service) is needed.In one embodiment, the request may be initiated by a customer andreceived via a telephone call, an email, a support chat, a text message,or any form of communication. In another embodiment, the request may beinitiated by device (for example, a connected device that can sense theneed for a service and communicate that need to a service provider,sometimes referred to as an “IoT device”). The request may includeinformation identifying the location where the technical service isrequested (e.g., an address).

Reference is now made to FIG. 1, which shows an example of a system 100for scheduling tasks to field professionals 110. In one embodiment,system 100 may represent a computer-based system that may includecomputer system components, desktop computers, workstations, tablets,handheld computing devices, memory devices, and/or internal network(s)connecting the components. System 100 may include or be connected tovarious network computing resources (e.g., servers, routers, switches,network connections, storage devices, etc.) necessary to support theservices provided by system 100. In one embodiment, system 100 mayinclude a customer service unit 120 configured to receive a set ofrequests for on-site technical assistance from users 130 and/or directlyfrom IoT devices 140. Customer service unit 120 may also scheduleappointments with field professionals 110 for providing the on-siteservice based on the availability of with field professionals 110 andsystem constraints. In another embodiment, system 100 may include a taskscheduling unit 150 for processing the received requests in view of theexisting schedule of tasks and provide recommendations for appointmentsthat enable greater optimization of scheduling all the fieldprofessionals as a whole. In another embodiment, system 100 may provideservice provider 160 statistics based on an analysis of informationreflective of the service performances. Network 170 may facilitatecommunications and data exchange between different system components andthe different entities associated with system 100.

Consistent with the present disclosure, task scheduling unit 150 mayinclude a server 152 and a database 154. In one example configuration,server 152 may be a cloud server that processes request receiveddirectly (or indirectly) from one or more users 130 and determine, basedon the requests, a set of daily schedules of tasks for fieldprofessionals 110. The term “cloud server” refers to a computer platformthat provides services via a network, such as the Internet. In thisexample configuration, server 152 may use virtual machines that may notcorrespond to individual hardware. For example, computational and/orstorage capabilities may be implemented by allocating appropriateportions of desirable computation/storage power from a scalablerepository, such as a data center or a distributed computingenvironment. In one example, server 152 may implement the methodsdescribed herein using customized hard-wired logic, one or moreApplication Specific Integrated Circuits (ASICs) or Field ProgrammableGate Arrays (FPGAs), firmware, and/or program logic which, incombination with the computer system, cause server 152 to be aspecial-purpose machine.

As depicted in FIG. 1, server 152 may be coupled to one or more physicalor virtual storage devices such as database 154. Server 152 may accessdatabase 154 to determine, for example, the availability of fieldprofessionals 110 and to use historical data to predict factors that mayaffect the completion of tasks. Database 154 may utilize a volatile ornon-volatile, magnetic, semiconductor, tape, optical, removable,non-removable, or other type of storage device or tangible ornon-transitory computer-readable medium. Database 154 may also be partof server 152 or separate from server 152 as shown. When database 154 isnot part of server 152, for example, server 152 may exchange data withdatabase 154 via a communication link as shown.

Database 154 may include one or more memory devices that store data andinstructions used to perform one or more features of the disclosedembodiments. In one embodiment, database 154 may include any suitabledatabases, ranging from small databases hosted on a workstation to largedatabases distributed among data centers. Database 154 may also includeany combination of one or more databases controlled by memory controllerdevices (e.g., server(s), etc.) or software. For example, database 154may include document management systems, Microsoft SQL databases, SharePoint databases, Oracle™ databases, Sybase™ databases, other relationaldatabases, or non-relational databases, such as mongoDB™ and others.

Consistent with the present disclosure, task scheduling unit 150 mayexchange data with a variety of communication devices 180 associatedwith the different entities associated with system 100. The term“communication device” is intended to include all possible types ofdevices capable of exchanging data using communications network 170. Insome examples, the communication device may include a smartphone, atablet, a mobile station, a personal digital assistant, a desktop, alaptop, an IoT device (e.g., IoT device 140), a dedicated terminal, andany other device that enables data communication. In one embodiment,task scheduling unit 150 may provide to a field professionalcommunication device 180A information reflecting the assignment of tasksand receive progress information derived at least partially from alocation circuit of communication device 180A. In another embodiment,task scheduling unit 150 may present to a customer service communicationdevice 1808 possible time slots for scheduling new technical servicesand receive a selection of appointments. In another embodiment, taskscheduling unit 150 may transmit to a user communication device 180Cupdates about an oncoming technical service and receive feedback aboutpreviously completed tasks. In another embodiment, task scheduling unit150 may present a service provider communication device 180D arecommendation for reducing the number of future unscheduled tasks andreceive a desired scheduling weight for different task types.

Consistent with the present disclosure, communications network 170 maybe any type of network (including infrastructure) that supportscommunications, exchanges information, and/or facilitates the exchangeof information between the components of system 100. For example,communications network 170 may include or be part of the Internet, aLocal Area Network, wireless network (e.g., a Wi-Fi/302.11 network), orother suitable connections. In other embodiments, one or more componentsof system 100 may communicate directly through dedicated communicationlinks, such as, for example, a telephone network, an extranet, anintranet, the Internet, satellite communications, off-linecommunications, wireless communications, transponder communications, alocal area network (LAN), a wide area network (WAN), a virtual privatenetwork (VPN), and so forth.

The components and arrangements shown in FIG. 1 are not intended tolimit the disclosed embodiments, as the system components used toimplement the disclosed processes and features may vary. In oneembodiment, task scheduling unit 150 may include a set of servers 152,with each server 152 hosting a certain type of service. For example, afirst server may host a native scheduling engine for scheduling, and asecond server may compare in a stateless manner the data associated withthe scheduled tasks using an optimization engine to detect if the nativescheduling engine scheduled tasks in an unoptimized manner.

FIG. 2 is a block diagram of example configurations of server 152 andcommunication device 180. In one embodiment, both server 152 andcommunication device 180 includes a bus 200 (or other communicationmechanism) that interconnects subsystems and components for transferringinformation within server 152 and/or communication device 180. Forexample, bus 200 may interconnect a processing device 202, a memoryinterface 204, a network interface 206, and a peripherals interface 208connected to I/O system 210.

Processing device 202, shown in FIG. 2, may include at least oneprocessor configured to execute computer programs, applications,methods, processes, or other software to perform embodiments describedin the present disclosure. For example, the processing device mayinclude one or more integrated circuits, microchips, microcontrollers,microprocessors, all or part of a central processing unit (CPU),graphics processing unit (GPU), digital signal processor (DSP), fieldprogrammable gate array (FPGA), or other circuits suitable for executinginstructions or performing logic operations. The processing device mayinclude at least one processor configured to perform functions of thedisclosed methods such as a microprocessor manufactured by Intel™. Theprocessing device may include a single core or multiple core processorsexecuting parallel processes simultaneously. In one example, theprocessing device may be a single core processor configured with virtualprocessing technologies. The processing device may implement virtualmachine technologies or other technologies to provide the ability toexecute, control, run, manipulate, store, etc., multiple softwareprocesses, applications, programs, etc. In another example, theprocessing device may include a multiple-core processor arrangement(e.g., dual, quad core, etc.) configured to provide parallel processingfunctionalities to allow a device associated with the processing deviceto execute multiple processes simultaneously. It is appreciated thatother types of processor arrangements could be implemented to providethe capabilities disclosed herein.

In some embodiments, processing device 202 may use memory interface 204to access data and a software product stored on a memory device or anon-transitory computer-readable medium. For example, server 152 may usememory interface 204 to access database 154. As used herein, anon-transitory computer-readable storage medium refers to any type ofphysical memory on which information or data readable by at least oneprocessor can be stored. Examples include random access memory (RAM),read-only memory (ROM), volatile memory, nonvolatile memory, harddrives, CD ROMs, DVDs, flash drives, disks, any other optical datastorage medium, any physical medium with patterns of holes, a RAM, aPROM, and EPROM, a FLASH-EPROM or any other flash memory, NVRAM, acache, a register, any other memory chip or cartridge, and networkedversions of the same. The terms “memory” and “computer-readable storagemedium” may refer to multiple structures, such as a plurality ofmemories or computer-readable storage mediums located withincommunication device 180, server 152, or at a remote location.Additionally, one or more computer-readable storage mediums can beutilized in implementing a computer-implemented method. The term“computer-readable storage medium” should be understood to includetangible items and exclude carrier waves and transient signals.

Both communication device 180 and server 152 may include networkinterface 206 coupled to bus 200. Network interface 206 may provide atwo-way data communication to a network, such as network 170. In FIG. 2,the communication between communication device 180 and server 152 isrepresented by a dashed arrow. In one embodiment, network interface 206may include an integrated services digital network (ISDN) card, cablemodem, satellite modem, or a modem to provide a data communicationconnection to a corresponding type of telephone line. As anotherexample, network interface 206 may include a local area network (LAN)card to provide a data communication connection to a compatible LAN. Inanother embodiment, network interface 206 may include an Ethernet portconnected to radio frequency receivers and transmitters and/or optical(e.g., infrared) receivers and transmitters. The specific design andimplementation of network interface 206 depends on the communicationsnetwork(s) over which communication device 180 and server 152 areintended to operate. For example, in some embodiments, communicationdevice 180 may include network interface 206 designed to operate over aGSM network, a GPRS network, an EDGE network, a Wi-Fi or WiMax network,and a Bluetooth® network. In any such implementation, network interface206 may be configured to send and receive electrical, electromagnetic oroptical signals that carry digital data streams representing varioustypes of information.

Both communication device 180 and server 152 may also includeperipherals interface 208 coupled to bus 200. Peripherals interface 208be connected to sensors, devices, and subsystems to facilitate multiplefunctionalities. In one embodiment, peripherals interface 208 may beconnected to I/O system 210 configured to receive signals or input fromdevices and providing signals or output to one or more devices thatallow data to be received and/or transmitted by communication device 180and server 152. In one example, I/O system 210 may include a touchscreen controller 212, audio controller 214, and/or other inputcontroller(s) 216. Touch screen controller 212 may be coupled to a touchscreen 218. Touch screen 218 and touch screen controller 212 can, forexample, detect contact, movement or break thereof using any of aplurality of touch sensitivity technologies, including but not limitedto capacitive, resistive, infrared, and surface acoustic wavetechnologies as well as other proximity sensor arrays or other elementsfor determining one or more points of contact with the touch screen 218.Touch screen 218 can also, for example, be used to implement virtual orsoft buttons and/or a keyboard. While a touch screen 218 is shown inFIG. 2, I/O system 210 may include a display screen (e.g., CRT or LCD)in place of touch screen 218. Audio controller 214 may be coupled to amicrophone 220 and a speaker 222 to facilitate voice-enabled functions,such as voice recognition, voice replication, digital recording, andtelephony functions. The other input controller(s) 216 may be coupled toother input/control devices 224, such as one or more buttons, rockerswitches, thumbwheel, infrared port, USB port, and/or a pointer devicesuch as a stylus.

With regards to communication device 180, peripherals interface 208 mayalso be connected to an image sensor 226 for capturing image data. Theterm “image sensor” refers to a device capable of detecting andconverting optical signals in the near-infrared, infrared, visible, andultraviolet spectrums into electrical signals. The electrical signalsmay be used to form an image or a video stream (i.e., image data) basedon the detected signal. The term “image data” includes any form of dataretrieved from optical signals in the near-infrared, infrared, visible,and ultraviolet spectrums. Examples of image sensors may includesemiconductor charge-coupled devices (CCD), active pixel sensors incomplementary metal-oxide-semiconductor (CMOS), or N-typemetal-oxide-semiconductor (NMOS, Live MOS). In some cases, image sensor226 may be part of a camera included in communication device 180.According to some embodiments, peripherals interface 208 may also beconnected to a motion sensor 228, a light sensor 230, and a proximitysensor 232 to facilitate orientation, lighting, and proximity functions.Other sensors (not shown) can also be connected to the peripheralsinterface 208, such as a temperature sensor, a biometric sensor, orother sensing devices to facilitate related functionalities. Inaddition, a GPS receiver can also be integrated with, or connected to,communication device 180. For example, a GPS receiver can be built intomobile telephones, such as smartphone devices. GPS software allowsmobile telephones to use an internal or external GPS receiver (e.g.,connecting via a serial port or Bluetooth).

Consistent with the present disclosure, communication device 180 may usememory interface 204 to access memory device 234. Memory device 234 mayinclude high-speed random-access memory and/or non-volatile memory suchas one or more magnetic disk storage devices, one or more opticalstorage devices, and/or flash memory (e.g., NAND, NOR). Memory device234 may store an operating system 236, such as DARWIN, RTXC, LINUX, iOS,UNIX, OSX, WINDOWS, or an embedded operating system such as VXWorkS. Theoperating system 236 can include instructions for handling basic systemservices and for performing hardware-dependent tasks. In someimplementations, the operating system 236 can be a kernel (e.g., UNIXkernel).

Memory device 234 may also store communication instructions 238 tofacilitate communicating with one or more additional devices, one ormore computers and/or one or more servers. Memory device 234 can includegraphical user interface instructions 240 to facilitate graphic userinterface processing; sensor processing instructions 242 to facilitatesensor-related processing and functions; phone instructions 244 tofacilitate phone-related processes and functions; electronic messaginginstructions 246 to facilitate electronic-messaging related processesand functions; web browsing instructions 248 to facilitate webbrowsing-related processes and functions; media processing instructions250 to facilitate media processing-related processes and functions;GPS/navigation instructions 252 to facilitate GPS and navigation-relatedprocesses and instructions; capturing instructions 254 to facilitateprocesses and functions related to image sensor 226; and/or othersoftware instructions 258 to facilitate other processes and functions.Memory device 234 may also include application specific instructions 260to facilitate a process for providing real-time information about aprogress of a field professional assigned to a number of tasksassociated with a subset of requests.

Each of the above identified instructions and applications maycorrespond to a set of instructions for performing one or more functionsdescribed above. These instructions need not be implemented as separatesoftware programs, procedures, or modules. Memory device 234 may includeadditional instructions or fewer instructions. Furthermore, variousfunctions of communication device 180 may be implemented in hardwareand/or in software, including in one or more signal processing and/orapplication specific integrated circuits. For example, communicationdevice 180 may execute an image processing algorithm to identify objectsin a received image. In addition, the components and arrangements shownin FIG. 2 are not intended to limit the disclosed embodiments. As willbe appreciated by a person skilled in the art having the benefit of thisdisclosure, numerous variations and/or modifications may be made to thedepicted configuration of server 152. For example, not all componentsmay be essential for the operation of server 152 in all cases. Anycomponent may be located in any appropriate part of server 152, and thecomponents may be rearranged into a variety of configurations whileproviding the functionality of the disclosed embodiments. For example,some servers may not include some of the elements shown in I/O system210.

FIGS. 3A and 3B depict two schematic maps illustrating the planned dailyschedule of two field professionals and the updated daily schedule ofthe two field professionals. As shown in FIG. 3A, the first fieldprofessional was assigned to tasks for providing technical service atlocations A, B, C, D; and the second field professional was assigned totasks for providing technical service at locations E, F, G, H. Theplanned route of the first field professional is illustrated in a dashedline and the planned route of the second field professional isillustrated in a solid line. Assuming that the first field professionalwas scheduled to be at location “A” at 10:36 and at location “B” at11:39; and the second field professional was scheduled to be at location“E” at 10:15 and at location “F” at 11:09. In the illustrated example,server 152 received at 9:15, from network interface 206, real-timeinformation for the first and second field professionals. In oneembodiment, the real-time information may include current locationinformation derived at least partially from location circuits of fieldprofessionals' communication devices 180A. For example, the real-timeinformation may indicate that first field professional is stuck on theroad to location “A.” In another embodiment, the real-time informationmay include task status updates transmitted from field professionals'communication devices 180A. For example, the real-time information mayindicate that the second field professional had finished the assignmentearlier than the estimated time for the completion of the taskassociated with location “E.” Based on the real-time progressinformation, and as shown in FIG. 3B, server 152 may reassign the firstfield professional to a task associated location “F,” and reassign thesecond field professional to a task associated location “A.” Thus, theupdated schedule of first field professional includes tasks associatedwith locations F, B, C, and D and the updated schedule of second fieldprofessional includes tasks associated with locations E, A, G, H.

Consistent with the present disclosure, server 152 may determine fromreal-time information a delay associated with one or more tasks assignedto a first field professional, and that there is a likelihood that thedelay will interfere with the first field professional arriving at anidentified location associated with an assigned task at a scheduledtime. For example, at 9:15, server 152 may determine that the firstfield professional cannot make it to location “A” before 9:40.Therefore, server 152 may reassign the assigned task to a second fieldprofessional based on the real-time information and the determinedlikelihood that the delay will interfere with the first fieldprofessional arriving at location “A” at 10:36. Server 152 may providethe second field professional, using network interface 206, informationreflecting the assignment of the task associated with location “A.” Inone embodiment, the information reflecting the assignment of the firsttask includes directional instructions to location “A” (e.g., alocation, an address, a driving route). In another embodiment, theinformation reflecting the assignment of the first task includes detailsabout a customer associated location “A” (e.g., a name, a phone number).In another embodiment, the information reflecting the assignment of thefirst task includes a description of the first task (e.g., tools, spareparts, existing infrastructure).

FIG. 4 provides a high-level illustration of system 100, according toembodiments of the disclosure. It illustrates the integrated access,management and analysis to service operations data within oneorganization, and the interaction with other organizations. Also shownis the interaction with other corporate Management Information Systems(MIS). The figure shows server 152, using database 154 (which may be aset of synchronized databases) to support a client software operated byusers concerned with some combination of the basic service managementtasks. System 100 may include an analysis module 441, a forecastingmodule 442, a planning module 443, a scheduling module 444, and adatabase access module (not shown). Modules 441, 442, 443, and 444 maycontain software instructions for execution by at least one processingdevice, e.g., processing device 202. The function of the modules isdescribed in detail below.

Consistent with the present disclosure, server 152 may extractinformation, and convey management decisions, to other units, including:human resources 431 for interacting with information about availablestaff, their calendars (i.e., vacation, training, overtime, etc.) andtheir mix of skills (which may be affected by changes in trainingplans); finance 432 for examining, and reporting, the implications ofdecisions such as authorizing overtime or subcontracting some work; andcustomer relationship management 433 for interacting with past andcurrent data of detailed and aggregated customer demands. FIG. 4 alsoshows how two or more organizations using the same system may make theiroperations and cooperation much more effective by automaticallytransmitting relevant information between their servers. One example isoutsourcing, in which a planning decision in organization A (marked as410) to outsource work to organization B (marked as 420) may be conveyedto organization B, and appears there as a change in forecast demand,requiring re-iteration of the planning process. Such an arrangement mayenable a large service organization to form customer-facing portals andsubcontractor-facing portals to streamline and optimize its operations.This subcontractor-facing portal is also known as B2B(Business-to-Business) application, as well as “private marketplace” or“public marketplace” depending on their openness.

According to the present disclosure, analysis module 441, forecastingmodule 442, planning module 443, scheduling module 444, database accessmodule, and database 154 may cooperate to perform multiple operationsassociated with the assignment of field professionals. For example,forecasting module 442 may include macro-level forecasting software,which analyzes past demand and actual service operations performance,together with expected future events (e.g., new product launch) topredict demands aggregated or separated along the different types ofdecisions that characterize customer demand and the decision inherent inanswering a customer demand. While some of the data used comes fromanalysis module 441, forecasting module 442 may be used as adecision-making tool letting managers define their expectations (out ofthe different possible predictions and scenarios) and commit to thedecision that planning should proceed in a manner consistent with thesedecisions.

Planning module 443 may include macro-level planning software foranalyzing demands at various aggregation levels and rough allocation ofresources to meet these demands. This module supports the analysis ofexpected demands side-by-side with allocated resources, checking theimpact of various resource-management decisions on the organization'scapability to meet demands (including “what-if” analysis” and managingdifferent alternative scenarios concurrently), and communicating theplanning decisions so that they are used in furtheroperations—scheduling, workforce management, training etc.

Scheduling module 444 may include micro-level planning software forassigning specific values to the different characteristic of each task,including resource assignments, time scheduling and geographic routing.Analysis module 441 may include reporting and querying tool for dataanalysis and datamining at all levels, from most general to mostspecific, across any dimension. The analysis may support bothhuman-initiated drill-down and ad-hoc querying and comparisonoperations, as well as intelligent software-directed data mining tools.This module may be concerned mostly with analysis of existing data, andnot with any decision-making.

According to some embodiments, server 152 may distinguish between threetypes of aggregated demands: group A: aggregated demands originatingfrom a projected forecast; group B: aggregated demand originating fromcustomers who present their demand in an aggregated way only, forexample “I need 5000 hours of telephone installation in August”; andgroup C: individualized, itemized known demand that is aggregated into agroup B demand, because a temporary concern is made only to a roughcapacity assessment question, or to a rough resource allocation. At anygiven point of time and for a certain time duration, a manager ofservice provider 160 may be interested in the aggregated answers for theentire demand (A+B+C) for that time duration. Yet for the more immediatehorizon, and for the part of group C individualized demand required inthis time duration, the manager of service provider 160 may need to havethe micro-level scheduling plan from scheduling module 444.

The integrated nature of system 100 enables service provider 160 to takethe most appropriate path between the options described below, mixingand integrating between work flows, hierarchical levels, and hierarchiesalong any dimension (i.e., hierarchies of time scales,intra-organizational and inter-organizational structures, geographicalregions, demand types, skill sets etc.). For example, in someembodiments, server 152 may use the forecasting module 442 to collecthistorical information as well as future-event information (e.g., newproduct launch) in order to generate and refine group A demands; useplanning module 443 for macro-level planning on group A+B+C; runscheduling module 444 on itemized group C; run analysis module 441 onthe schedule of itemized group C to obtain information. The obtainedinformation may include: for a user-specified time period, what are thetotal number of service calls delivered in each of the geographicregions; for any given service professional, for a user-specified timeperiod, what customers did he work for, how many hours for each one, andthe total for that professional; for any given customer, for auser-specified time period, which field professionals worked for him,and the total work and costs; division of work time between actualon-site work, travel, region, service field professional's seniority orskills, and other general or specific data associated with a time ofyear, etc. (e.g., training, vacation, and absences). In addition, server152 may use the information from analysis module 441 to modify andrefine forecasting module 442 and planning module 443 decisions. Forinstance, the average time duration of tasks.

In other embodiments, server 152 may exploit the capabilities ofsupporting multiple hierarchies, aggregations, and discrepancydetection, to support the process of conciliating downward-flowingmanagement decisions with upward-flowing information from the workforceas well as from existing and potential customers. In one example, server152 may use forecasting module 442 (assisted by analysis module 441) togenerate demand predictions on a detailed level (e.g., per each regionand/or per each demand type) and propagate the sums upwards to presenthigher-level aggregations (also referred to herewith as “bottom-up”forecasting). In another example, server 152 may use forecasting module442 (assisted by analysis module 441) to generate high-level aggregateddemand predictions, combine them with management guidelines (e.g.,ratios between demand types, training quotas, ratio of travel time toon-site time) and propagate these forecasts downwards (also referred toherewith as “top-down” forecasting). In another example, server 152 mayuse forecasting module 442 to detect and resolve discrepancies betweenhigh-level and low-level forecast numbers, and between divisions acrossdifferent dimensions (e.g., size of demand isolated across regional,temporal, and demand-type dimensions). In another example, server 152may use planning module 443 to allocate resources on a detailed level(e.g., per each region and/or per each demand type) and propagate thesums upwards to present higher-level aggregations (also referred toherewith as “bottom-up” planning). In another example, server 152 mayuse planning module 443 to generate higher-level aggregated resourceallocations, combined with management guidelines (e.g., budget, overtimepolicies) and propagate these plans downwards (also referred to herewithas “top-down” planning). In another example, server 152 may use planningmodule 443 to detect and resolve discrepancies between high-level andlow-level resource allocation numbers, and between divisions acrossdifferent dimensions (e.g., size of demand separated across regional,temporal and demand-type dimensions).

In other embodiments, server 152 may have the capability to iterativelygo back to decisions and commitments made in any prior step and changethem. When such a change is made, system 100 may propagate the effectsof the change across all the affected data, hierarchies, and decisions.When such a propagation results in a discrepancy, the problem may beautomatically highlighted and service provider 160 may be optionallypresented with a list of possible decisions that may resolve theproblem.

The following is one example illustrating this capability: using theforecasting module 442, Jane, an organization's service manager,generates a top-level resource allocation plan for the coming quarter(e.g., Q4). David, a manager for region A, now needs to refine thedetails of Jane's top-level plan for the coming quarter. Jane hasallocated for region A enough resources to satisfy the projected demandsfor that region. However, using planning module 443 to assessregion-specific needs and forecasting, as reflected by forecastingmodule 442. David finds that there will not be enough resources in hisregion to cover an expected demand for a specific task type (e.g., notenough service engineers are qualified for network installation).Optionally, planning module 443 may suggest several possibleresolutions, such as outsourcing, transferring resources from anotherregion, and allowing more overtime. David chooses to resolve thediscrepancy by transferring resources from another region. He contactsJoe, a manager of neighboring region B, to check whether Joe has asurplus of resources for network installation. If so, David and Joe needto check the extra costs and mileage involved in the additional travel(optionally this may be another feature of planning module 443), andrecord their agreement using planning module 443 so that Jane can see itin detail and in aggregation. If Joe cannot help David, and after Davidhas tried some other solutions (e.g., outsourcing, adding overtime),David will need to ask Jane for additional resources to be allocated inthe plan for region A. Jane then records the extra allocation, andDavid's planning module view shows that his region should be ready tomeet the demands. This is an example of modifying an earlier messagemade in the same module (Planning), with automatic propagation whichremoves the discrepancy-report for region A, and optionally also updatesinformation in the human resources, finance, and other systems. Mary,who is in charge of training in the human resources department, uses herown views of analysis module 441, forecasting module 442 and planningmodule 443 to identify the problem in region A. If the analysis module441 and forecasting module 442 show that this problem is expected topersist, she modifies training plans and quotas to ensure that the skilldistribution—at least in region A—would have a better fit to the demanddistribution. This is an example of automatic propagation to systemsoutside of those described in the disclosure. In the meantime, regionC's manager has solved that region's lack of resources by negotiating anoutsourcing agreement with Alice, who owns a smaller local servicebusiness. Alice enters this as a demand in her own forecasts and usesplanning module 443 to make sure that she has enough resources tofulfill the expected demands, together with this new obligation. This isan example of supporting the coordination of planning anddecision-making across organizational boundaries.

Time has passed and it is now Monday evening at the beginning of Q4.David (the manager of region A) has received a list of demands forservice to be completed the next day. He uses scheduling module 444 tooptimize the dispatch—which service engineer will handle which demand ortasks at which time, according to various factors, including customer'sservice level agreement, customer location, service engineer's skills,and spare parts inventory. Scheduling module 444 automatically takesinto account the rough allocations made in planning module 443,including decisions such as “reserve engineers with network-installationskills, as many as possible for network-installation demands”; and “ifpossible, keep spare time for service professionals who are based nearthe boundary with region B, since the plan lets region B's managerhandle expected demands by requesting assignment of region A resources.”After more time has passed, in the middle of Q4, it turned out that someof the predictions were not substantially accurate. Joe, the manager ofregion B, uses analysis module 441 to determine why he experienceddifficulties in scheduling day-to-day calls, and discovers that thedistribution between the north part of his region and the south part hassomewhat deviated from expectations, with the south region having largedemands and necessitating too much travel in the north. Usingforecasting module 442, he updates the aggregate intra-regional demandexpectations which automatically highlights a discrepancy in planningmodule 443 versus the existing resource allocation. Joe can now resolvethis discrepancy using his own resources, using outsourcing; or by usinganalysis module 441 to check whether any for the neighboring regions tohis south has unexpected surplus resources, and then negotiate with thatregion's manager; or by addressing the problem to the manager for thewhole organization. These interactions are supported by a shared accessto the data, features, and views provided by analysis module 441,forecasting module 442, planning module 443 and scheduling module 444.This illustrates the capability to propagate the effects of new data andnew decisions across several different modules, planning horizons, andhierarchy structures, as well as preventing the repeated occurrence ofmicro-level problems (e.g., difficulty in servicing a specific requeston a specific day) by feedback via analysis and forecasting intomodified planning and allocation.

In other embodiments, server 152 may have the capability to bring insimulation tools as a well-integrated part of the performance trackingprocess to predict problems and check possible solutions as soon aspossible. Allocating enough resources to meet the expected demand may benot enough, even after taking account of various times not used foractual service—e.g., training, vacations, health problems—and for timespent in travel between tasks. To achieve more accurate predictions, afollowing simulation may be made, according to the present disclosure. Astatistical demand characteristic obtained from historical datacollected by scheduling module 444 and aggregated using analysis module441. These characteristics will describe demand as divided along thedifferent dimensions and their related hierarchies, e.g., region andtype of demand. Forecasting module 442 may be used to project thesecharacteristics into the future period of interest. Planning module 443may be used to allocate resources matching the forecasted demands. Astochastic method may be used to generate a number of hypotheticalsamples of a typical day's demands, randomly drawn according to thestatistical distributions generated in the previous step. Schedulingmodule 444 may be used to schedule each of these sets of demands, usingthe resources assigned by the planning module 443. Analysis module 441may be used to aggregate the detailed results obtained by schedulingmodule 444, and to check whether the resources indeed matched the demandunder simulated fully detailed operation. A resource allocation utilityat planning module 443 may be used to modify resource allocation at theappropriate level (e.g., it may be revealed that the only need may be tochange allocation between sub-divisions of one region). The simulationmay be repeated if necessary, to reveal conditions that may createproblems in the future.

In other embodiments, server 152 may have the capability to facilitatethe integration of decision processes and management levels, differentusers (or the same users in different steps of their work). To do so,server 152 may use different ways of analyzing, viewing, aggregating, ordis-aggregating (“drilling down”) data. For example, server 152 may haveaccess to data with at least one field that includes work hours, tools,spare parts, overtime allotments. The source for each field may comefrom the forecasting (prediction of required resources), allocation(decisions on resources made available to operations), or actual data(for times prior to present). Optionally, there may be differentsubtypes of each source, as when there are several forecasts forAugust—one from the forecast made in January, one from the forecast madein April, etc., the system is set to display one or more sources for thesame field, each with its own values, and optionally highlightdiscrepancies between the sources. In addition, some values maypropagate from a previous stage, as when the expected work hours acrossthe whole organization are derived by summing of the expected work hoursas reported by each division manager. Other values are propagated from alater stage, as when an Operations Manager has set the work-hour budgetfor the whole organization, which needs to be divided between theregions. Both directions may—and often do—coexist, and the system may beset to display either of them, or both, and optionally highlightdiscrepancies between the directions.

In other embodiments, server 152 may have the capability to supportscenarios for decision-support and “what if” tools. A scenario comprisesa set of data, which is inserted into the system (e.g., forecasts, staffsize) and a set of decisions (e.g., extended overtime, outsourcing,constraining the allocation of some resources so that they may be usedonly—or preferentially—for demands of specific type or region). Eachscenario may generate its own set of data, viewable and editable throughthe system. As the decision process evolves, some scenarios aremodified, some are split to compare different “decision forks,” and someare deleted, until a preferred scenario remains and becomes the basisfor an actual decision.

As mentioned above, the actions performed by the manager of serviceprovider 160 while using one view automatically propagated by thesoftware across other views, hierarchy levels, and planning periods.They may also be propagated across organization boundaries, as when aplanning-decision in organization A to outsource work to organization Bis conveyed to organization B and appears there as a change in forecastdemand, requiring re-iteration of the planning process. According tosome embodiments, when propagating these actions, the systemautomatically monitors for discrepancies. The discrepancies may include:(1) Discrepancies between a forecast demand and allocated resources. (2)Discrepancies between different sources of the same information (e.g.,forward-looking simulation vs. extrapolation of data using statisticaltrends analysis). (3) Discrepancies between different propagationdirections, as when the planned resources are both dictated by highermanagement, propagating downwards, and also reported by regionalmanagement, propagating upwards. (4) Discrepancies between commitmentsmade to customers and actual ability to deliver: For example, a customermay call with a problem and be told “someone will be with you tomorrowbetween 13:00 and 17:00,” because there appeared to be enough freeresources during that time window, and without committing specificresources. Later there will be more calls are received and the softwaredetermines that there will be difficulty meeting this commitment,alerting the manager early enough to act, e.g., by diverting resourcesfrom another region. Another example for an even shorterplanning-period: identifying the situation in which the service engineeris delayed in traffic or in an earlier task and will probably fail toarrive on time to the next task.

The system may provide alerts to draw the user's attention todiscrepancies. Optionally, the alerts consist of color-coding of areasin the view (e.g., cells in a displayed table) according to the presenceand severity of discrepancies. Optionally, the alerts may includepresenting to the user a list of alerts, possibly ranked and color-codedby their severity. Optionally, the alerts may include messagestransmitted to users defined as being in charge of reacting and/orresolving each type of alert. Messages may be transmitted by phone,cellular messaging, e-mail, fax, and instant messaging. In addition, thealerts may include of any combination of the above mechanisms,configurable according to the user's personal preferences, user type,alert type, and organizational procedures.

FIG. 5 is a conceptual illustration of a three-tier architectural model500 for managing data retrieval within an information system is shown inaccordance with embodiments of the present disclosure. The three-tierarchitectural model 500 includes a presentation layer 502, anapplication layer 504, and a data layer. Each of these layers (502, 504,and 506) may be software modules designed to interact with one anotherto provide a logical framework for managing retrieval of stored data forvarious other software modules in the information system. As a personskilled in the art would recognize, even though not explicitly statedwhen describing specific embodiments, any of the computer-implementedoperations performed by these layers (502, 504, and 506) may alsoinclude interaction with one or more hardware modules in the informationsystem.

Generally, presentation layer 502 may be responsible for manipulatingdata for the performance of an action. Such an action may include, forexample, rendering the data for display on a graphical user interface(GUI). Data layer 506 stores the data that is to be manipulated bypresentation layer 502. Application layer 504 may be an “intermediate”layer that serves as a communication liaison between presentation layer502 and data layer 506. That is, presentation layer 502 may issuerequests for retrieval of specified data stored in data layer 506 toapplication layer 504 rather than communicating directly with data layer506. In response to such a request, application layer 504 may retrievethe specified data from data layer 506 and provide a view of theretrieved data to presentation layer 502. The view presents thespecified data to presentation layer 502 in a manner such thatpresentation layer 502 may manipulate the data to perform a specifictask. For example, presentation layer 502 may display data presentedthrough a view on a display element of a graphical user interface. Priorto retrieving the specified data, application layer 504 may apply one ormore rules to the request in furtherance of managing retrieval of thedata for presentation layer 502. As described in more detail below,these rules relate to conditions that are designed to effectuate thetransfer of data between data layer 506 and presentation layer 502.

In one embodiment, each of these layers (502, 504, and 506) may resideon a single computing system. In another embodiment, at least one ofthese layers may reside on a computing system separate from the othertwo layers. For example, presentation layer 502 may reside on a clientcomputer system and application 504 and data layer 506 may both resideon a server computer system. Even further, each layer may reside on aseparate computing system from the other. In either of these latterembodiments, a communications network may be employed for communicationsbetween the layers residing on separate computer systems. It should beappreciated that each of the layers operate regardless of whether thelayers reside on a single computing system or multiple computingsystems.

Presentation layer 502 may include software modules and processes(collectively, “components”) of application programs that use datastored in data layer 506 to perform actions. Example actions mayinclude, without limitation, rendering information for display on a GUIpresented to users through a display monitor. It should be appreciatedthat these actions may relate to any form of data manipulation orprocessing, and therefore are not limited to rendering data for displayon a GUI. Indeed, many components of application programs manipulatedata during “background” operations that are not noticeable to users ofthe computing system. These types of actions may be performed eitherrandomly or following scheduled, periodic time periods. For illustrativepurposes, however, presentation layer 502 may be described as acomponent requesting data from data layer 506 for use in manipulatingthe data to render a display for a GUI. In one embodiment, presentationlayer 502 may be built on top of AngularJS framework and utilize singlepage application (SPA) architecture. Using modular approach,presentation layer 502 may provide unified visual design language anduser experience. The different services described in the disclosure maybe implemented as modules within this layer. For mobile access, thepresentation layer may include applications for most popular mobileoperating systems, such as iOS, Android, and Windows, and deployed fromcorresponding application stores.

Data layer 506 is configured to store data in the form of filestructures, each having a standard identifier, e.g., path and file name,recognizable to application layer 504 and data layer 506. In order torequest specific data stored in data layer 506, a request by a componentof presentation layer 502 includes, i.e., specifies, the standardidentifier for the data. Upon receiving a request from the component,application layer 504 manages retrieval of the specified data from datalayer 506 based on the standard identifier and thereafter provides aview of the retrieved data to the requesting component. The viewpresents the specified data to the presentation layer in a manner suchthat the data may be manipulated to perform a specific action.Consistent with the present disclosure, data layer 506 may have a puremulti-tenant architecture, providing both security and privacy tocustomers and unity to the system development and deployment. Forexample, the infrastructure may include a relational database, which maybe used dynamically to obtain high integrity control while maintaining acustomizable schema for each customer. In one embodiment, a plurality ofcustomers may share the same type of database, as well as the same typeof tables. Each table may be partitioned according to the customeridentity which enables the system to protect the security and privacy ofthe customer data. Although the same type of tables is used by aplurality of customers, the system includes a mechanism which enablesproviding different schema per customer, without the need to executeData Definition Language (DDL) commands and simply using references tothe relevant column as the customer defined. This ability enables us toperform online schema changes efficiently and safely without anydowntime to the customers, and without any code change. This flexibilityallows each customer to customize the product according to theirspecific business needs, while using a software product on the cloud.This flexibility also enables the system to provide fully localizableproduct to the customers, which enables international companies to usethe same product in multiple languages. In one embodiment, updatingobjects may be performed using optimistic locking which ensures that, ifparallel requests arrive, isolation of the transaction may be kept whilestill keeping data integrity.

In accordance with the architectural model 500, the responsibilitiesand/or operations of application layer 504 may be performed by varioussoftware modules into which application layer 504 is divided. Inaccordance with one embodiment, application layer 504 may be responsiblefor receiving requests from components of presentation layer 502 fordata stored in data layer 506 and providing the requesting componentswith a view of the specified data. In another embodiment, applicationlayer 504 may be responsible for the actual retrieval, and subsequentcaching, of the specified data. Consistent with the present disclosure,application layer 504 may include implementation for a highlycustomizable object manipulation framework allowing it to utilize all ofthe benefits of data layer 506 and provide for the developer's genericability to work with business data objects. For example, applicationlayer 504 may enable object definition, CRUD operations, advanced searchcapabilities, and object serialization for web access, includingRESTful, SOA, and XML over HTTP methods. In one embodiment, on top ofthe abilities of data layer 506, this layer provides memory cachingmechanism, which allows high performance for infrequently updatedobjects and dramatically reduces the number of queries for the datalayer. For example, application layer 504 may have search capabilitiesfor objects included in memory by indexing and grouping mechanismsimplementing proprietary object query language allowing a sophisticatedmix of SQL executed queries within memory validated conditions. In oneembodiment, application layer 504 may utilize a stateless architecturalapproach and may not maintain any state data between sequential calls.For example, all state data may be serializing in the database by theend of each call, and during a next call requesting some data, the mostupdated state data is then obtained from the database. As animplementation for the multi-tenant paradigm, application layer 504 mayensure high data and access isolation on the tenant and user level andallow a highly configurable ability to define, set data, and accesscontrols on a user, group of users, role, and tenant level.

Consistent with the present disclosure, the services on the cloudenvironment architectural model 500 may be highly available and maysimultaneously work on multiple availability zones. Production andstaging environments are isolated on virtual cloud network level. As ascalability model, the system may utilize POD approach when multi-tenantdeployments segmented and isolated in completely independent parts. Inorder to reduce latency and comply with laws of different countries,such as the General Data Protection Regulation (GDPR) in Europe andmore.

A. Task Scheduling Based on Real-Time Conditions

Disclosed and claimed is a system that receives real-time reports (e.g.,traffic updates, weather conditions), predicts that a field professionalwill not be able reach the customer at the scheduled time, and reassignsthe customer to a different field professional. In one example, thesystem predicts that the field professional will miss a future task inhis daily schedule. In another example, the system predicts that a delaywould cause one or more tasks to be completed after a shift of a fieldprofessional is about to end.

FIG. 6A is a flowchart of an example process 600 for task schedulingbased on real-time conditions, consistent with the present disclosure.In some embodiments, server 152 may implement process 600. For example,processing device 202 may receive data from I/O system 210 or networkinterface 206, and then execute instructions or program codes stored inmemory interface 204 or database 154, in which the instructions orprogram codes implement algorithms of process 600. The algorithms ofprocess 600 may be implemented as one or more of analysis module 441,forecasting module 442, planning module 443, or scheduling module 444.Process 600 includes the following steps or operations.

At step 602, processing device 202 determines real-time scheduleinformation for field professionals 110 independent from any scheduleupdate received from field professionals 110 via network interface 206.The real-time schedule information may include any information or dataassociated with task schedules of the field professionals 110 updated orreceived in real time. In some embodiments, processing device 202 maydetermine real-time schedule information from communication device 180A.In some embodiments, the real-time information may be determined byprocessing device 202 without intervention of field professionals 110,such as in predetermined intervals or triggered by predetermined events.

In some embodiments, the real-time schedule information may reflect afield professional's progress in attending, performing or completingtasks. For example, the real-time schedule information may reflectlocation information associated with the professional. Based on thelocation information, system 100 (alone or with reference to otherinternal or external systems) may determine if a field professional isat a location associated with one of the tasks in the schedule or enroute to a scheduled task. For another example, the real-time scheduleinformation may reflect task updates (e.g., field professionals 110 mayuse a dedicated communication device or a dedicated application toprovides real-time updates, such as, “arrived at destination,” “taskcompleted,” “set out for next destination,” etc.). For another example,the real-time schedule information may include updates from differentdata sources outside system 100 that may affect the progress of fieldprofessionals 110 (e.g., traffic updates, weather updates, user's socialprofiles, etc.).

In some embodiments, the real-time schedule information may reflectrequired changes to a schedule of a field professional. For example,system 100 may determine that a schedule of field professionals 110needs to be changed and provide real-time schedule informationreflecting the schedule change with optionally varying degrees ofspecificity (e.g., as in FIGS. 3A-3B, after completing the task at pointA, go to point F and not to point B). For another example, a client maydirectly inform a field professional that he/she is running late for alocation of a scheduled task.

In some embodiments, the real-time schedule information may includecurrent location information derived at least partially from locationcircuits of communication devices of field professionals 110 withoutintervention of field professionals 110. In some embodiments, thecommunication devices may include mobile devices (e.g., a smartphone) orvehicles that is associated with field professionals 110. For example,the communication devices may include communication device 180A. Thelocation circuit may be, for example, a global positioning system (GPS)circuit module. In some embodiments, the current location informationmay be derived from the location circuits without intervention of fieldprofessionals 110, such as in predetermined intervals.

In some embodiments, the real-time information may include real-timeweather conditions associated with field professionals 110. For example,the weather conditions may be associated with regions that coverscurrent locations of field professionals 110. In some embodiments, theweather conditions may be received from a third-party service provider,such as an Internet server of a weather forecast service provider. Insome embodiments, the weather conditions may be received from thethird-party service provider without intervention of field professionals110, such as in predetermined intervals.

In some embodiments, the real-time schedule information may be receivedfrom communications network 170. In some embodiments, fieldprofessionals 110 may initiate sending schedule update via communicationdevice 180, but such schedule update is independent from the real-timeschedule information determined by processing device 202. In otherwords, processing device 202 may receive the real-time scheduleinformation automatically without affirmatively reporting of fieldprofessionals 110. For example, processing device 202 may send a requestat a predetermined time interval to communication device 180A to obtainthe real-time schedule information.

In some embodiments, processing device 202 may receive progressinformation for field professionals 110 from network interface 206. Theprogress information may include any number of any combination of thereal-time schedule information that is determined by processing device202 without intervention of field professionals 110 and the scheduleupdate sent by field professionals 110. In some embodiments, theschedule update may include task updates initiated by fieldprofessionals 110 (e.g., field professionals 110 may use a dedicatedcommunication device or a dedicated application to provides updates,such as, “arrived at destination,” “task completed,” “set out for nextdestination,” etc.) or shift updates initiated by field professionals110 (e.g., field professionals 110 may use a dedicated communicationdevice or a dedicated application to provides real-time updates, suchas, “shift stated,” “shift completed,” “shift interrupted,” etc.).

In some embodiments, the progress information may include task statusupdates transmitted from communication devices of field professionals110. For example, the task status updates may be transmitted in a formof text messages. For another example, the task status updates may betransmitted in a form of application data inputted by fieldprofessionals 110 through a user interface to a dedicated applicationinstalled in the communication devices (e.g., a smartphone).

Referring back to FIG. 6A, at step 604, processing device 202determines, from the real-time schedule information associated with afirst field professional, existence of a delay associated with one ormore tasks assigned to the first field professional. The first fieldprofessional may be one of field professionals 110. The first fieldprofessional may have one of more tasks assigned thereto. For example,as shown in FIGS. 3A-3B, the first field professional was assigned totasks for providing technical service at locations A, B, C, D. The delaymay be represented as a time difference between a current time and thescheduled arrival time of a location associated with a task assigned tothe first field professional to perform at the location. Consistent withthe present disclosure, the delay may be associated with a difficultyfor completing a scheduled task, no matter the cause of the difficulty.For example, the delay may result from traffic conditions due severeweather conditions. Alternatively, the delay may result from a failureof the field professional to complete an earlier task within anallocated time frame. Alternatively, the delay may result from acustomer not being present at the location.

FIG. 6B is a diagram of example planned and actual schedules of fieldprofessionals, consistent with the present disclosure. In FIG. 6B, thefirst field professional P1 corresponds to the first field professionalin FIG. 3A, and each of locations A-D may have a specified or scheduledarrival time for P1. Each row of blocks represents a schedule associatedwith a field professional in FIG. 6B. White blocks represent the fieldprofessional's time durations when performing a task at a specifiedlocation or when the field professional is available. Dotted blocksrepresent the field professional's time durations when driving betweenthe specified locations. A timeline is shown below the blocks, and dashlines are shown to indicate aligned time points of the schedules in thetimeline.

For the first field professional P1, two schedules are shown: one forP1's planned schedule, and one for P1's actual schedule. In P1's plannedschedule, P1's scheduled arrival times for locations A-D are 10:36,11:39, 12:20, and 13:15. The delay associated with the one or more tasksmay occur when the first field professional arrives at the locationslater than the scheduled times. For example, in P1's actual schedule, P1misses the scheduled arrival time of 10:36 for location A. In otherwords, at the scheduled arrival time 10:36, P1 is still driving. In thisexample, the delay may be represented as a time difference between acurrent time and the scheduled arrival time 10:36.

In some embodiments, the real-time schedule information may include acurrent time and a current location of the first field professional. Bycomparing the current time and location of the first field professionalwith expected time and location thereof, processing device 202 maydetermine the existence of the delay. For example, assuming thescheduled arrival time is 10:36 for location A and the first fieldprofessional leaves the starting point (FIG. 3A) at 10:00, if thecurrent time is 10:18 but the current location of the field professionalis at ¼ of the total distance from the starting point to location A,processing device 202 may determine the existence of the delay.

In some embodiments, the real-time schedule information may include thereal-time weather conditions. The scheduled arrival times at tasklocations may be determined based on a first assumed weather condition,such as a sunny weather. When the real-time weather condition isdifferent from the assumed weather condition, the arrival times may bedelayed. For example, if the real-time weather condition is raining, theroad conditions may become worse and the traffic may become slower, bywhich the first field professional may delay arriving at schedule times.If that is the case, processing device 202 may determine the existenceof the delay.

In some embodiments, if processing device 202 receives the progressinformation from network interface 206 at step 602, processing device202 may determine a delay associated with one or more tasks assigned tothe first field professional. In some embodiments, processing device 202may determine the delay from the progress information.

At step 606, processing device 202 determines a likelihood that thedelay will interfere with the first field professional arriving at anidentified location associated with an assigned task at a scheduledtime. The scheduled time may be a time specified by processing device202 for the first field professional to arrive at the identifiedlocation. For example, the identified location may be any of locationsA-D in FIG. 3A. Though processing device 202 determines the existence ofthe delay at step 604, the delay may not necessarily cause an actualdelay of the arrival time at the identified location. For example, thefirst field professional may find means (e.g., find a shorter route orincrease moving speed) to make up for the delay.

In some embodiments, processing device 202 may apply a traffic routemodel reflecting one or more possible routes for the first fieldprofessional to travel to the identified location for determining thelikelihood that the delay will interfere with the first fieldprofessional arriving at the identified location at the scheduled time.Traffic conditions may affect driving durations between locationsassigned to the first field professional.

In some embodiments, the traffic route model may include a model thatassigns different weights to different segments of routes. A weight mayhave a value proportional to a likelihood that a delay would occur whena field professional travels through it. The weight may be assigned inaccordance to historical data, such as statistics of traffic conditionsand speed limits. In some embodiments, the total weight of a route maybe a sum of the weights of its segments. To apply the traffic routemodel, processing device 202 may select the one or more possible routesfor the first field professional from all routes to travel to theidentified location. Processing device 202 may then determine the totalweights for each of the possible routes. In some embodiments, if thefirst field professional is on the way to the identified location andall of the possible routes have a total weight corresponding to alikelihood greater than a predetermined threshold (e.g., 50%),processing device 202 may determine that the delay will interfere withthe first field professional arriving at the identified location at thescheduled time.

In some embodiments, processing device 202 may apply a task performancemodel for determining the likelihood that the delay will interfere withthe first field professional arriving at the identified location at thescheduled time. In some embodiments, the task performance model mayinclude a model that assigns different weights to different tasks. Aweight may have a value proportional to a likelihood that a delay wouldoccur when a field professional performs a specific task. The weight maybe assigned in accordance to historical data, such as statistics of taskperformances. The weight may also be assigned in accordance todifficulty level of the tasks, such as complexity and time duration toperform it. To apply the task performance model, processing device 202may determine the type of task the first field professional isperforming, such as from task information. Processing device 202 maythen determine the weight for the task. In some embodiments, if the taskbeing performed by the first field professional has a total weightcorresponding to a likelihood greater than a predetermined threshold(e.g., 50%), processing device 202 may determine that the delay willinterfere with the first field professional arriving at the identifiedlocation (e.g., the next location for a future task) at the scheduledtime.

In some embodiments, processing device 202 may determine a likelihoodthat the delay will interfere with a future assigned task. The futureassigned task may be a task scheduled later than the current task. Forexample, in FIG. 3A, if the first field professional is currentlyworking at location A for a first task, a second task at location B isthe future assigned task. In some embodiments, processing device 202 maydetermine a likelihood that the delay in the current task will interferewith the future assigned task using a delay-statistics model. In someembodiments, the delay-statistics model may collect and compilehistorical delay data and generate correlations between a time durationof the delay at the current task and a likelihood of such delay causinga time duration of a delay at the future task. For example, statisticsmay show that that a five-minute delay at 10:00 for a first task willcause an 80% likelihood that the first field professional will be 30minutes late to a second task scheduled at 15:00. The delay-statisticsmodel may establish a corresponding relationship between the 5-minutedelay and the 30-minute delay for the two tasks. When the first fieldprofessional actually delay for 5 minutes at the first task, by usingthe delay-statistics model, processing device 202 may determine that thelikelihood is 80% for the first field professional to arrive 30 minuteslate for the second task.

In some embodiments, to determine a likelihood that the delay willinterfere with a future assigned task, processing device 202 may obtainweather conditions associated with locations of tasks assigned to thefirst field professional and adjusting time estimations for completionof the tasks based on the weather conditions. When the task is performedoutdoor, the weather condition may affect the task completion time. Theweather condition may also affect travel durations between locationsassigned to the first field professional. In some embodiments,processing device 202 may obtain the weather conditions from athird-party service provider. To determine a likelihood that a weathercondition will cause delay for the completion time, processing device202 may also use a weather-statistics model. The weather-statisticsmodel may collect and compile historical weather condition data andgenerate correlations between a weather condition at a location of atask and a likelihood of such weather condition causing a delay for thecompletion time. When the first field professional is performing thecurrent task and the weather condition changes, by using theweather-statistics model, processing device 202 may determine that thereis a specific likelihood for the first field professional to delay thecompletion time of the current task. Based on the likelihood, processingdevice 200 may adjust time estimation for completion of the currenttask.

In some embodiments, to determine a likelihood that the delay willinterfere with a future assigned task, processing device 202 may obtaintraffic conditions associated with locations of tasks assigned to thefirst field professional and predicting times that the first fieldprofessional would arrive these locations based on the trafficconditions. In some embodiments, processing device 202 may predict thearrival times of the first field professional use the traffic routemodel and the delay-statistics model. For example, by obtaining thetraffic conditions and inputting it into the traffic route model and thedelay-statistics model, processing device 202 may determine likelihoodsthat the traffic conditions will cause the first field professional todelay for different time durations to arrive the different locations.Based on those likelihoods, processing device 202 may determine thepredicted arrival times. As an example, Table 1 shows originallyestimated driving duration between the starting point and location A inFIG. 3 and corresponding predicted driving durations updated usingreal-time traffic conditions at different times of a day. In Table 1,each row represents a time of the day.

TABLE 1 Time Estimated driving duration Updated driving duration 10:0025 minutes 55 minutes 10:15 25 minutes 55 minutes 10:30 27 minutes 52minutes 10:45 27 minutes 45 minutes 11:00 30 minutes 40 minutes 11:15 30minutes 35 minutes 11:30 35 minutes 35 minutes 11:45 35 minutes 35minutes 12:00 30 minutes 30 minutes

In some embodiments, processing device 202 may determine a likelihoodthat the delay will interfere with the first field professionalcompleting all assigned tasks prior to a predesignated shift completiontime. In some embodiments, to determine the likelihood, processingdevice may use a statistics model that is modified based on anycombination of the traffic route model, the task performance model, thedelay-statistics model, and the weather-statistics model. The statisticsmodel may collect and compile historical data and generate correlationsbetween a time duration of the delay and a likelihood of such delaycausing an overtime for the first field professional. For example,statistics may show that that a one-hour delay at 10:00 for a first taskwill cause an 90% likelihood that the first field professional will beunable to completing all assigned tasks prior to a predesignated shiftcompletion time at 18:00. The statistics model may establish acorresponding relationship between the one-hour delay and the 90% ofovertime likelihood. When the first field professional actually delayfor one hour, by using the statistics model, processing device 202 maydetermine that the likelihood is 90% that the first field professionalwill be unable to completing all assigned tasks prior to thepredesignated shift completion time.

Referring back to FIG. 6A, at step 608, processing device 202 determinesfrom real-time schedule information associated with a second fieldprofessional whether the second field professional can arrive to theidentified location associated with the task assigned to the first fieldprofessional at the scheduled time. The second field professional may beone of field professionals 110. For example, the second fieldprofessional may be the field professional assigned to tasks forproviding technical service at locations E, F, G, H in FIGS. 3A-3B. Insome embodiments, processing device 202 may determine whether the secondfield professional can arrive at the identified location at the scheduletime based on any combination of the traffic conditions, weatherconditions, or task performances associated with the second fieldprofessional.

For example, as shown in FIG. 6B, processing device 202 may determinefrom real-time schedule information that the first field professional P1will delay arriving at location A at scheduled time 10:36, and thesecond field professional P2 has finished a task at location E at 10:12,sooner than expected completion time at 10:39. Based on the trafficcondition from location E to location A, weather conditions at locationsE and A, or the type of the task to be performed at location A,processing device 202 may determine that the second field professionalcan arrive to location A at 10:36.

At step 610, processing device 202 reassigns the task assigned to thefirst field professional based on the real-time schedule informationassociated with the first field professional and the real-time scheduleinformation associated with the second field professional.

In some embodiments, processing device 202 may reassign the taskassigned to the first field professional by assigning it to the secondfield professional. For example, as shown in FIG. 6B, processing device202 may reassign the task associated with P1 at location A to P2. Inother words, P2 will go to location A after finishing task at location Erather than location F as originally scheduled. In some embodiments,processing device 202 may reassign the task associated with P2 atlocation F to P1. In other words, P1 will go to location F rather thanlocation A as originally scheduled.

In some embodiments, prior to reassigning the task to the second fieldprofessional, processing device 202 may determine whether the secondfield professional has required skills and parts to complete the task.If the second field professional has the required skills and parts tocomplete the task, processing device 202 may reassign it to the secondfield professional. For example, as shown in FIG. 6B, processing device202 may determine whether P2 has required skills and parts to completethe task at location A before reassigning the task associated with P1 atlocation A to P2.

In some embodiments, processing device 202 may reassign the assignedtask to the second field professional based on the determined likelihoodthat the delay will interfere with the first field professional arrivingat the identified location associated with the assigned task at thescheduled time. For example, if the determined likelihood exceeds apredetermined threshold (e.g., 50%), processing device 202 may reassignthe task to the second field professional.

In some embodiments, to reassign the task assigned to the first fieldprofessional to the second field professional, processing device 202 mayidentify a number of second field professionals who can complete thetask assigned to the first field professional, and select the secondfield professional based on current location information of the numberof second field professionals and traffic conditions. In someembodiments, at step 608, processing device 202 may determine that thereare multiple second field professionals who can arrive to the identifiedlocation associated with the task assigned to the first fieldprofessional at the scheduled time. Further, processing device 202 mayselect the second field professional based on the current locationinformation of the second field professionals and the trafficconditions. For example, processing device 202 may determine the secondfield professional as the field professional having the shortest arrivaltime from the multiple second field professionals. In some embodiments,processing device 202 may determine the second field professional basedon other criteria, such as skill levels, workload of the day, completedwork of the day, future work scheduled, and so forth. For example,processing device 202 may assigned a weight and a score to each of thecriteria. The weight represents the level of importance of thatcriterion in the determination of the second field professional. Thescore represents the degree, extent, or scale of the criterion.Processing device 202 may determine a weighted score for each of themultiple second field professionals and select one with its weightedscore in a predetermined range.

In some embodiments, to reassign the task assigned to the first fieldprofessional to the second field professional, the second fieldprofessional may be selected based on estimated costs. The costs mayinclude travel distances, wages, overtime pay, or the like. For example,processing device 202 may estimate a cost for each of the number ofsecond field professionals who can complete the task assigned to thefirst field professional, and select the second field professionalfurther based on estimated costs. In some embodiments, processing device202 may select the second field professional as the one having thelowest cost among the multiple second field professionals. To determinethe costs, in some embodiments, processing device 202 may also assign aweight and a score to each of the factors of the costs. The weightrepresents the level of importance of that cost factor in thedetermination of the second field professional. The score represents thevalue of the cost. Processing device 202 may determine a weighted scorefor each of the multiple second field professionals and select one withits weighted score in a predetermined range.

In some embodiments, if processing device 202 determines, at step 606, alikelihood that the delay will interfere with the first fieldprofessional completing all assigned tasks prior to the predesignatedshift completion time, processing device 202 may reassign one or moretasks to the second field professional, thereby avoiding causing thefirst field professional to work overtime. For example, the second fieldprofessional may be associated with the same predesignated shiftcompletion time. For another example, the second field professional maybe associated with a later predesignated shift completion time.

In some embodiments, selecting the second field professional includesreassigning a task currently assigned to the second field professionalto a third field professional. In some embodiments, the third fieldprofessional may actually be the best candidate for such reassignment(e.g., having the shortest traveling time or the lowest cost), but hisor her availability may be unclear because he or she is in the middle ofa task. If the likelihood is high that the third field professional cancomplete his or her current task soon, processing device 202 mayconditionally reassign the task of the first field professional to thesecond field professional, on condition that the third fieldprofessional does not complete his or her current task in time. If thethird field professional does complete his or her current task in time,processing device may reassign the task conditionally reassigned to thesecond field professional to the third field professional.

In some embodiments, processing device 202 may receive an indicationfrom the first field professional about inability to complete allpending tasks in a daily schedule. Processing device 202 may thenidentify a plurality of second field professionals who can completepending tasks in the daily schedule of the first field professional, andreassign the pending tasks to at least two second field professionals.Processing device 202 may further provide the at least two second fieldprofessionals, using network interface 206, information reflecting thereassignment. In some embodiments, the indication about inability tocomplete all pending tasks in a daily schedule may include an injury, afamily emergency, or a sudden, personal event. The informationreflecting the reassignment may be any information for indicating atleast some contents of the reassignment. In some embodiments, theinformation reflecting the reassignment may include information about aplan of the reassignment, such as rescheduling the task to a new dataand time for the first field professional, or reassigning the task to asecond field professional to complete. For example, the informationabout the plan may include the new data and time if the task isrescheduled, or a name of the second field professional if the task isreassigned thereto. In some embodiments, the information reflecting thereassignment may include directional instructions to accessing tasklocations, such as an address or a driving route.

In some embodiments, processing device 202 may reassign the task byrescheduling the task to a date and time where the first fieldprofessional is available. In some embodiments, processing device 202may reassign the task in accordance with company policies. The companypolicies may include different rules that specifies the way ofreassignment under different conditions. For example, the companypolicies may specify that when the first field professional delay morethan 10 minutes, the task assigned to the first field professional mustbe reassigned to the second field professional. The company policies mayalso specify that if the task is reassigned to the second fieldprofessional and would cause the second field professional to detour fora time longer than a predetermined threshold (e.g., 30 minutes), thetask must be rescheduled to a date and time where the first fieldprofessional is available. In some embodiments, the company policies maybe implemented as computer-readable instructions as conditions inalgorithms, which may be stored in database 154 accessible via memoryinterface 204 and executed by processing device 202.

Referring back to FIG. 6A, at step 612, processing device 202 providesto at least one of the first field professional and the second fieldprofessional, using network interface 206, information reflecting thereassignment of the task. In some embodiments, processing device 202 maysend the information to the communication devices associated with thefirst field professional and the second field professional, such ascommunication device 180A.

In some embodiments, processing device 202 may provide a customerassociated with the assign task, using network interface 206,information indicative of the reassignment. The customer may be one ofusers 130. In some embodiments, processing device 202 may send theinformation to the communication device associated with the customer,such as communication device 180C. In some embodiments, the informationindicative of the reassignment may include a name, an expected arrivaltime, and contact information (e.g., a phone number) of the second fieldprofessional.

B. Work Capacity Planning

Disclosed is a system that improves work capacity in task scheduling byassigning different types of tasks to field professionals based onreal-time conditions. In some embodiments, the system may be implementedas task scheduling unit 150. The types of tasks may include productinstallation, product repair, product maintenance, product replacement,product diagnostics, customer consulting, or the like. The real-timeconditions may be associated with specific demand categories, such thatthe system may change a ratio between the types of scheduled tasks bylimiting the time windows that can be scheduled for a specific demandcategory. In one example, the system may limit the tasks for installinga first product to 70% of the available time windows (also known as timeslots). This means that only 30% of the available time windows may beassigned to tasks associated with other products. By inputting suchreal-time conditions to the system, the system may optimize workcapacity for task scheduling and increase throughput of task scheduling.

FIG. 7A is a flowchart of an example process 700A for scheduling tasksto field professionals, consistent with the present disclosure. In someembodiments, server 152 may implement process 700A. For example,processing device 202 may receive data from I/O system 210 or networkinterface 206, and then execute instructions or program codes stored inmemory interface 204 or database 154, in which the instructions orprogram codes implement algorithms of process 700A. The algorithms ofprocess 700A may be implemented as one or more of analysis module 441,forecasting module 442, planning module 443, or scheduling module 444.Process 700A includes the following steps or operations.

At step 702, processing device 202 receives a set of requests reflectingdemand for services. The set of requests may be associated with a numberof task types. In some embodiments, the requests reflecting the demandfor services may be data including instructions to request remoteservices. For example, the remote services may include marketing,surveys, business development, searches and other services that does notrequire the presence of the service providers. In other embodiments, therequests reflecting the demand for services may be data includinginstructions to request on-site services. For example, the on-siteservices may include installing Internet services, setting up utilityservices, repairing a telephonic device, replacing plumbing devices, orthe like. In some embodiments, the set of requests may be sent by any ofthe customer service unit 120 (e.g., via communication device 180B),users 130 (e.g., via communication device 180C), or IoT devices 140. Theservices may be services requested to be performed by professionalson-site or by remote service providers. In some embodiments, the numberof task types may include different types of service. For example, thetask types may include product installation, product repair, productmaintenance, product replacement, product diagnostics, customerconsulting, or the like. In some embodiments, the number of task typesmay include different types of products. For example, the task types maycorrespond to different product categories, product models, productmanufacturers, or the like. It is noted that the terms “task type,”“task classification,” and “demand category” may be used interchangeablyherein and may refer to any distinguishable characteristic of a task forfield professionals.

At step 704, processing device 202 receives availability data indicativeof an availability of field professionals 110 or the remote serviceproviders to perform the services. Available field professionals orremote service providers may be scheduled to perform the services. Theavailability data may be any data that indicates or represents theavailability of field professionals 110. For example, the availabilitydata may include any symbolic or numeric value that indicates a fieldprofessional is available or unavailable for a new task. In someembodiments, processing device 202 may receive the availability datafrom field professionals 110 (e.g., via communication device 180A). Insome embodiments, processing device 202 may receive the availabilitydata from database 154. In some embodiments, processing device 202 maydetermine the availability data from inputs from field professionals 110associated with a period time. For example, a field professional maysubmit his or her personal schedule conflicts to server 152 via networkinterface 206. The submission may be performed daily, weekly, monthly,or in any appropriate interval. In some embodiments, processing device202 may determine the availability data from personal records of fieldprofessionals 110. For example, the personal records may includescheduled holidays, vacations, leaves, or any off-duty time periods. Insome embodiments, the personal records may be stored in database 154.

At step 706, processing device 202 receives skills data indicative ofcapabilities of each of field professionals 110 or remote serviceproviders with respect to the task types. The skill data may include anyclassification of resource that indicates the capabilities of each offield professionals 110 or remote service providers to perform a workassociated with a demand category. Field professionals capable ofperforming the task types may be scheduled to perform the on-siteservices. The skills data may be any form of data associated with afield professional or a remote service provider and indicative of thecapabilities of the field professional. In some embodiments, the skillsdata may be stored as a database record. For example, the skills datamay include data indicative of years of experience, categories ofcapabilities, certificates of the capabilities, levels of skills, pastperformance records, titles, team roles, or the like.

In some embodiments, processing device 202 may receive the skills datafrom field professionals 110 (e.g., via communication device 180A). Insome embodiments, processing device 202 may receive the skills data fromdatabase 154. In some embodiments, processing device 202 may determinethe skills data from personal records of field professionals 110. Forexample, the personal records may include information representingqualifications, seniority, skill levels, years of affiliation, or thelike. In some embodiments, the personal records may be stored indatabase 154.

In some embodiments, processing device 202 may determine the skills databased on ranking associated with customers' feedback of fieldprofessionals 110. For example, the customers' feedback may includescores, stars, comments, answers to multiple-choice questions, emails,phone calls, letters, or the like. The ranking may be determined basedon a number-based process (e.g., by ranking the scores) or anopinion-based process (e.g., by evaluating the comments). In someembodiments, the opinion-based process may be implemented using amachine learning model capable of natural language processing. In someembodiments, the ranking of a field professional may be performed foreach of the task types the field professional is capable of performing.

Referring back to FIG. 7A, at step 708, processing device 202 obtains atleast one desired scheduling weight for the number of task types. Forexample, for each of the task types, processing device 202 may obtain adesired scheduling weight. The desired scheduling weight may be a value(e.g., a numeric, textual, alphabetic, or symbolic value) that indicatesa level of desirability of the task type by a customer. For example, ifthe desired scheduling weight is a numeric value, the numeric value mayindicate the level of the desirability. In some embodiments, highdesired scheduling weight may indicate high desirability of the tasktype, and processing device 202 may prioritize to schedule fieldprofessionals for such task type. For example, a task of installingdevices may have a lower desirability than a task of repairing devices,and the desired scheduling weight for the task of installing devices mayhave lower values (e.g., a value of 0.3) than the task of repairingdevices (e.g., a value of 0.8). It should be noted that the values ofthe desired scheduling weight may be set to be within any range and notlimited to the examples described herein.

In some embodiments, to obtain the at least one desired schedulingweight, processing device 202 may receive an input indicative of the atleast one desired scheduling weight. In some embodiments, the input maybe adjusted according to circumstances. For example, processing device202 may receive the input in real time. For another example, processingdevice 202 may receive the input in a predetermined interval. Foranother example, processing device 202 may receive the input on demandby a user of customer service unit 120. In some embodiments, the inputmay be received from a member of customer service unit 120 (e.g., amanager). For example, processing device 202 may receive a desiredscheduling weight for repair as 0.4 (e.g., representing that the repairtasks take 40% of the available time slots for task scheduling), and adesired scheduling weight for installation as 0.6 (e.g., representingthat the installation tasks take 60% of the total scheduled tasks).Processing device 202 may assign each task of repair with the weight 40%and each task of installation with the weight 60%. For another example,the member of customer service unit 120 may desire to allocate moreresources to support a new product than to an old product. In thisexample, the input may include a first weight (e.g., 0.8) for the newproduct and a second weight (e.g., 0.2) for the old product, in whichthe first weight may be greater than the second weight. Consistent withthe present disclosure, the desired scheduling weight may correspondwith a scheduling limit, such that a scheduling restriction may beplaced on a first task type without placing a restriction on a secondtask type. The scheduling limit may be indicative of the percentage ofthe available time windows that can be scheduled for the first tasktype. For example, the system may avoid from scheduling more than 10% ofthe available time windows to tasks for repairing a certain product.

In some embodiments, the scheduling weight may be set as correlated witha period of time, such as a month, a season, a year, or any length ofany period of time. For example, a task of installing Internet devicesmay be highly demanded in a summer, and the scheduling weight for such atask may be set as higher than the scheduling weights in other times ofthe year. For another example, a task of repairing electricalapparatuses may be highly demanded after a heavy snowstorm, and thescheduling weight for such a task may be set as higher than thescheduling weights after normal weather conditions.

In some embodiments, the scheduling weight may be set as correlated witha geographic region, such as a city, a county, a community, or any sizeof any geographic region. For example, a task of installing telephonicdevices may be highly demanded in an urban area, and the schedulingweight for such a task may be set as higher than the scheduling weightsin other geographic regions. For another example, a task of maintainingelectrical apparatuses may be highly demanded in a rural region, and thescheduling weight for such a task may be set as higher than thescheduling weights in other geographic regions.

In some embodiments, to obtain the at least one desired schedulingweight, processing device 202 may use artificial intelligence (AI) todetermine the at least one desired scheduling weight for increasingthroughput. In some embodiments, the AI may be implemented as a softwaremodule in task scheduling unit 150. For example, the AI may receive amarketing goal as input, and based on market data (e.g., stored indatabase 154), determine the desired scheduling weight to meet themarketing goals. The marketing goal may be, for example, increasingcustomer satisfaction on product maintenance in September. Based on sucha marketing goal, the AI may increase the desired scheduling weight ofthe task type of product maintenance in September.

Referring back to FIG. 7A, at step 710, processing device 202 generatesa schedule for field professionals 110 based on the demand for services,the availability data, and the skills data. Consistent with the presentdisclosure, processing device 202 may determine scheduling policiesbased on available resources and wherein generating the schedule isbased on the scheduling policies. For example, when a certain tool istemporary disable, avoid scheduling certain tasks. In this embodiment,the available resources may include the field professionals themselves,working hours, vehicles, tools, equipment, spare parts, office space,and more. The schedule may be generated as any data that includesinstructions for field professionals 110 to complete work at specifiedlocations and time. For example, the schedule may include a promisedarrival time communicated to a customer, a destination of the customer,a route to the destination, or an expected arrival time determined basedon real-time information. Generating the schedule for fieldprofessionals 110 may include including a first task in the schedulewhen the first task conforms with the at least one desired schedulingweight and excluding a second task from the schedule when the secondtask does not conform with the at least one desired scheduling weight.For example, the first task may be installing a first product, and thesecond task may be repairing a second product. In some embodiments,conforming with the at least one desired scheduling weight may beimplemented as requiring a scheduling weight associated with a taskexceeding the desired scheduling weight. For example, the first andsecond tasks may be associated with a first and second schedulingweights, respectively. When the first scheduling weight is greater thanor equal to the desired scheduling weight, the first task may conformwith the at least one desired scheduling weight. When the secondscheduling weight is smaller than the desired scheduling weight, thesecond task may not conform with the at least one desired schedulingweight. In some embodiments, the first scheduling weight may be higherthan the second scheduling weight.

In some embodiments, the receipt order of the requests may beuncorrelated with generation of the schedule for field professionals110. For example, processing device 202 may receive a first requestassociated with the first task may and a second request associated withthe second task. For example, the first request may be received afterthe second request. The first and second requests may reflect demand forservices of the first and second tasks.

In some embodiments, processing device 202 may receive historical dataassociated with past demand for the task types. For example, thehistorical data may be data associated with past performed services andmay include statistics of numbers and types of demanded services (e.g.,on-site services). In some embodiments, the historical data may bezone-specific, such as grouped by different geographic regions.Different regions may have different statistics of demanded services.For example, an urban zone may be dominated by requests of Internetinstalling or repair services, and a rural zone may be dominated byrequests of electrical equipment maintenance services. In someembodiments, the historical data may be event-related, such as relatingto an inclement weather condition (e.g., a storm). For example, demandedservices of restoring utilities may spike after a big storm. In someembodiments, the historical data may be time-specific, such as groupedby certain days of a week, a month, or a year. Different days may havedifferent statistics of demanded services. For example, Mondays may bedominated by requests of Internet repair services, and Tuesdays may bedominated by requests of installing Internet services.

In some embodiments, processing device 202 may generate the schedule forfield professionals 110 based on a prediction of demand associated withthe received historical data. The prediction of the demand may begenerated based on the statistics of the numbers and types of thedemanded on-site services. For example, a frequency of an on-siteservice may be used as a probability to predict the likelihood of itsdemand. A scheduling weight of the on-site service may be determinedbased on the its frequency in the historical data. Processing device 202may then generate the schedule using its scheduling weight. For example,based on historical data, processing device 202 may predict a demand ofinstalling new Internet services is low in March. Based on suchprediction, processing device 202 may generate the March schedule withlower priority for field professionals 110 associated with Internetservice installation. In some embodiments, the prediction of the demandmay be determined using a machine learning model (e.g., implemented as asoftware model executable by processing device 202).

In some embodiments, processing device 202 may receive environmentaldata indicative of future events that affect completion of tasks. Forexample, the environmental data may include information reflecting aknown future event, such as a scheduled power blackout, infrastructuremaintenance (e.g., a road construction work), an atypical weathercondition, a public event (e.g., a parade), or the like. Such futureevents may limit resources available to field professionals 110 orinterfere with their ability to travel, thus affect the completion ofthe tasks. In some embodiments, processing device 202 may generate theschedule for field professionals 110 based on the environmental data.For example, processing device 202 may receive environmental dataindicative of a schedule blackout in a zone. Based on such environmentaldata, processing device 202 may generate the schedule for fieldprofessionals 110 to avoid working in the zone during the scheduledblackout.

In some embodiments, task scheduling unit 150 may reserve scheduleavailability associated with the desired scheduling weight. In thoseembodiments, processing device 202 may further schedule tasks that donot conform with the desired scheduling weight when a daily schedule offield professionals 110 is not full. For example, the desired schedulingweights for repair and installation may be 40% and 60%, respectively.Percentages of the actual schedules of repair and installation in thedaily schedules may be 20% and 60%, respectively. In other words, thedaily schedule of field professionals 110 is not full. In this example,if no requests for repair are received, processing device 202 mayschedule up to 60% of the tasks to installations and leaves only 40%room for repairs.

In some embodiments, processing device 202 may further provide, usingnetwork interface 206, to a field technician information reflecting anassignment of the first task. The field technician may be one of fieldprofessionals 110. The information reflecting the assignment of thefirst task may be provided as a text message, a website hyperlink, apush notification of a phone application, or the like. In someembodiments, processing device 202 may provide the information vianetwork interface 206 to communication device 180A.

In some embodiments, the information reflecting the assignment of thefirst task may include details about a customer associated with thefirst task. For example, the details may include a name, an accountnumber, or a phone number of the customer. In some embodiments, theinformation reflecting the assignment of the first task may includedescription of the first task. For example, the description may includea tool, a spare part, or an existing infrastructure, which may be neededby the first task. In some embodiments, the information reflecting theassignment of the first task may include directional instructions to anidentified location associated with the first task. For example, thedirectional instructions may include a location, an address, or adriving route of the customer.

FIG. 7B is a flowchart of another example process 700B for schedulingtasks to field professionals, consistent with the present disclosure. Insome embodiments, server 152 may implement process 700B. For example,processing device 202 may receive data from I/O system 210 or networkinterface 206, and then execute instructions or program codes stored inmemory interface 204 or database 154, in which the instructions orprogram codes implement algorithms of process 700B. The algorithms ofprocess 700B may be implemented as one or more of analysis module 441,forecasting module 442, planning module 443, or scheduling module 444.Process 700B includes the following steps or operations.

At step 712, processing device 202 receives a request for on-siteservice. Step 712 may be implemented in a way similar to step 702 inprocess 700A. At step 714, processing device 202 may determine a tasktype for the request. In some embodiments, corresponding relationshipsbetween task types and on-site services may be stored in database 154,such as database record entries. Processing device 202 may inquire thedatabase record entries to determine the task type for the receivedrequest. At step 716, processing device 202 selects a date forscheduling the task. In some embodiments, processing device 202 mayselect the date based on various factors, such as demand of the on-siteservice. For example, if the demand of the on-site service is not in anemergency (e.g., requested to be completed within five business days),processing device 202 may select a date not conflicting with the demand.FIG. 7C shows an example of selecting the date for scheduling the task.

FIG. 7C is a diagram of an example schedule for several fieldprofessionals, consistent with the present disclosure. The fieldprofessionals are Arnold, Bruce, Chuck, and Donald. The schedule showsassigned tasks and availability of each of the field professionalsbetween 8:00 and 16:00 of a workday. The assigned tasks have two types,a first type of task (e.g., installing services) shown as dense-dottedblocks, and a second type of task (e.g., repairing services) shown assparse-dotted blocks. Each of the field professionals are assigned withdifferent numbers of the two types of tasks in different times of day.For example, Arnold is assigned with 5 tasks in the workday, with thefirst, third, and fifth tasks of the first type and the second andfourth tasks of the second type. In FIG. 7C, Arnold, Bruce, and Chuckhave a full schedule for the workday, and Donald has an empty time slotafter his third task.

Processing device 202 may select this workday for scheduling thereceived task based on the demand of the on-site service. The demand mayinclude a time requirement of completion within five business days. Forexample, the on-site service may be of the second type, and schedulingthe on-site service does not conflict with the time requirement of thedemand of the on-site service (e.g., the workday in FIG. 7C is withinthe five-business day after receiving the request). Accordingly,processing device 202 may select the workday in FIG. 7C as the selecteddate.

At step 718, processing device 202 determines whether scheduling thetask in the selected date conforms with a scheduling limit associatedwith the task type. If scheduling the task in the selected date conformswith the scheduling limit associated with the task type, process 700Bproceeds to step 720. Otherwise, process 700B goes back to step 716, atwhich processing device 202 may select another date for scheduling thetask. Consistent with the present disclosure, process 700B may beadapted to be used in other implementations of system 100. For example,process 700B may be adapted to be used when optimizing task schedules.As discussed below, system 100 may review the schedule and providedschedule change recommendations to enable greater optimization ofscheduling all the field professionals as a whole. Before system 100provides a schedule changes recommendation, it may determine whetherscheduling the task in a recommended date conforms with the schedulinglimit associated with the task type. In one embodiment, system 100 mayuse a multi-route model to determine appointment availability. In oneexample, part of the routes may use a version of process 700B to confirmthat the scheduling limit associated with the task type is met. Forexample, in FIG. 7C, the first type of task has a desired schedulinglimit of 0.3, and the second type of task has a desired scheduling limitof 0.7. The desired scheduling limits of the first and second types oftasks may be obtained in a way similar to step 708 of process 700A. Suchdesired scheduling limit may reflect that the second type of tasks hashigher desirability higher than the first type of tasks. In thisexample, the condition of conforming with the scheduling limitassociated with the task type may be that, if a desired scheduling limitis smaller than 0.6, processing device 202 may schedule the first typeof tasks to the workday in FIG. 7C. That is, the received request ofon-site service will not be scheduled to the workday in FIG. 7C.Otherwise, if the desired scheduling limit is greater than or equal to0.6, processing device 202 may schedule the second type of tasks to theworkday in FIG. 7C. That is, the received request of on-site servicewill be scheduled to the workday in FIG. 7C. The description of thedesired scheduling limit has been set forth in descriptionscorresponding to step 708 of process 700A and will not be detailedhereinafter.

In the above example, at step 718, processing device 202 may determinethat scheduling the task in the selected date conforms with thescheduling limit associated with the task type because the task is ofthe second type and has a desired scheduling limit of 0.7, such that thereceived request of on-site service may be scheduled on the work day inFIG. 7C.

At step 720, processing device 202 selects a field professional forcompleting the task. For example, the workday of FIG. 7C is the selecteddate, and processing device 202 may select any of Arnold, Bruce, Chuck,and Donald as the selected field professional for completing the task.Processing device 202 may select the date based on various factors, suchas availability of the field professional and skills data of the fieldprofessional.

At step 722, processing device 202 determines whether the selected fieldprocessional has availability on the selected date. If the selectedfield processional has availability on the selected date, process 700Bproceeds to step 724. Otherwise, process 700B goes back to step 720, inwhich processing device 202 may select another field professional. Asshown in FIG. 7C, only Donald has availability (i.e., the empty timeslot) on the selected date. Processing device 202 may select Donald asthe selected field professional. In some other embodiments, if no fieldprofessional is available on the selected date, process 700B may goesback to step 720.

At step 724, processing device 202 determines whether skills of theselected field professional comply with the task. If the skills of theselected field professional comply with the task, process 700B proceedsto step 726. Otherwise, process 700B goes back to step 720, in whichprocessing device 202 may select another field professional. In someembodiments, the skills required for completing the on-site service mayinvolve certifications, past experience, past performance, customersatisfaction levels, years of experience, or any other indicatorsreflecting likelihood of successfully completing the requested on-siteservice of the selected field professional. Such skills may be stored asdata entries associated with the field professional in database 154, forexample. In some embodiments, processing device 202 may retrieve suchdata entries after selecting the field professional at step 722, anddetermine whether the field professional has required skills forcompleting the on-site service by comparing values of the data entriesto predetermined criteria. For example, if the requested on-site serviceinvolves repairing a device, processing device 202 may determine whetherDonald has a certificate to repair the device. At step 726, processingdevice 202 may schedule the task on the selected date to the selectedfield professional. For example, in FIG. 7C, processing device 202 mayschedule the task to Donald's empty time slot.

C. Using Predicted Demand to Optimize Task Scheduling

Disclosed and claimed is a system that implements predictive taskscheduling for field professionals by predicting service demand based onhistorical data and schedule field professionals under full availabilitythereof based on the predicted service demand. The system may reservesome availability of field professionals as redundancy for a time periodin a service schedule in case of emergencies that is likely to occur(but not yet occur when scheduling the field professionals) predicted byhistorical data. The predicated demand may include certain locations orcertain types of task. The system may also determine where to sendspecific field professionals with specific skill sets. In someembodiments, the system may be implemented as task scheduling unit 150.

FIG. 8A is a flowchart of an example process 800A for scheduling tasksto field professionals, consistent with the present disclosure. In someembodiments, server 152 may implement process 800A. For example,processing device 202 may receive data from I/O system 210 or networkinterface 206, and then execute instructions or program codes stored inmemory interface 204 or database 154, in which the instructions orprogram codes implement algorithms of process 800A. The algorithms ofprocess 800A may be implemented as one or more of analysis module 441,forecasting module 442, planning module 443, or scheduling module 444.Process 800A includes the following steps or operations.

At step 802, processing device 202 receives a set of requests reflectinga current demand for on-site services. Database 154 may be configured tostore historical data associated with past demand for fieldprofessionals. Processing device 202 is connectable to network interface206 for access database 154. The current demand may be a demand foron-site services that occur at a current time. In some embodiments, thecurrent demand may be an actual demand occurring at the current time,rather than a predicted demand. In some embodiments, the set of requestsmay be in a form of network data messages that may be received byprocessing device 202 via network interface 206. The historical data mayinclude any data reflecting statistics, attributes, environments, orcircumstances associated with past demands of on-site services. Forexample, the historical data may include statistical data reflectingfrequencies and number of times of past demands for each of the on-siteservices. The statistical data may be associated with attributes of thepast demands, such as a time period when such past demands were made, alocation where such past demands were performed, a traffic conditionwhen a field professional was reaching the location, a weather conditionwhen the field professional was reaching the location, a number ofdispatched field professionals, availability of field professionalsduring the time period, or any other related information.

In some embodiments, in addition to the set of requests, processingdevice 202 may further receive other data, such as traffic dataindicative of current traffic conditions and historical trafficconditions, or weather data indicative of a current weather condition.For example, the traffic data may include data reflecting roadconditions and level of traffic congestions of a region near thelocation of the on-site service or a route along with which a fieldprofessional may travel to reach the location of the on-site service.The traffic data may further include data reflecting past roadconditions and level of traffic congestions of the region near thelocation of the on-site service around the time when the on-site serviceis scheduled.

At step 804, processing device 202 predicts imminent demand for on-siteservices based on the historical data. The imminent demand may be anydemand that is likely to occur at a time close to a candidate scheduletime for the requests reflecting the current demand. For example, theimminent demand may be any sudden, improvised, urgent, emergent, orlast-minute demand made by customers (e.g., out of plan). Processingdevice 202 may predict the imminent demand using the historical data.For example, for a candidate schedule time for the requests reflectingthe current demand, processing device 202 may select a time periodbefore the candidate schedule time and retrieve statistical datareflecting frequencies and number of times of occurrence of suchimminent demands. Based on the statistical data, processing device 202may determine a likelihood reflecting a probability that a certainnumber of requests reflecting the imminent demands would be made withinthe time period before the candidate schedule time.

In some embodiments, when processing device 202 receives the trafficdata indicative of the current traffic conditions and the historicaltraffic conditions, processing device 202 may predict imminent trafficconditions based on the received traffic data. For example, based on thehistorical traffic conditions, processing device 202 may determine anaverage traffic condition (e.g., an average road condition or an averagelevel of traffic congestion) within the time period before the candidateschedule time as the predicted imminent traffic conditions.

In some embodiments, when processing device 202 further receives theweather data indicative of the current weather condition, processingdevice 202 may predict the imminent traffic conditions based on theweather data and the traffic data. For example, based on the weatherdata and average traffic condition as determined using the traffic datain the aforementioned embodiments, processing device 202 may adjust theaverage traffic condition in accordance with corresponding relationshipsbetween weather conditions and effects on traffic conditions (e.g., araining condition may delay traffic speed for 20%, while a snow stormmay delay traffic speed for 50%) to predict the imminent trafficconditions.

Referring back to FIG. 8A, at step 806, processing device 202 generatesa schedule for a set of field professionals based on the current demandfor on-site services. In some embodiments, the field professionals maybe assigned with tasks to complete the on-site services. Processingdevice 202 may schedule the tasks in one or more time slots. Forexample, the current demand may include different numbers of requests indifferent types, and processing device 202 may select fieldprofessionals capable to complete the requested on-site services andschedule the tasks in their available times.

In some embodiments, processing device 202 may determine the schedulefor the set of field professionals based on the predicted demand foron-site services and locations associated with the set of requests. Forexample, as shown in FIGS. 3A-3B, a type of on-site service is requestedat locations A, B, C, and D and a field professional (the first fieldprofessional P1) may be assigned to a task to complete such on-siteservices in locations A-D. In this example, processing device 202 maydetermine a schedule to complete the tasks in a temporal order ofD→C→B→A because a predicted demand of such on-site service at location Amay rise later that day. By arranging P1 to visit location A around thetime when predicted demand of such on-site service rises, P1 may be ableto respond to imminent demand of the same type of service aroundlocation A around the scheduled time. By doing so, total traveling timemay be saved and faster response to customer requests may be achieved.

In some embodiments, when processing device 202 receives the trafficdata indicative of the current traffic conditions and the historicaltraffic conditions, processing device 202 may generate the schedule forthe set of field professionals further based on the predicted trafficconditions. In the above example, processing device 202 may determine aschedule to complete the tasks in a temporal order of A→B→D→C afterconsidering the traffic data because processing device 202 may determinethat traffic conditions between C and D would be bad at a specific timeof day and the determined temporal order may allow P1 to avoidtravelling between C and D during that specific time. By doing so, atotal driving duration of P1 may be minimized.

In some embodiments, when processing device 202 further receives theweather data indicative of the current weather conditions, processingdevice 202 may generating the schedule for the set of fieldprofessionals further based on the current weather conditions. In theabove example, the current weather may be snowing, and processing device202 may determine a schedule to complete the tasks in a temporal orderof A→D→C→B after considering the traffic data and the weather databecause the traveling between A and B would be very slow due to the snowweather if route A→B→D→C is adopted. By adopting route A→D→C→B, P1 mayavoid the current snow and road conditions may improve for travelinglater that day. By doing so, a total driving duration of P1 may beminimized.

Referring back to FIG. 8A, at step 808, processing device 202 reservesin the schedule availability based on the predicted imminent demand foron-site services. To reserve availability in the schedule, processingdevice 202 may arrange tasks in a first time slot under fullavailability of field professionals, such as up to a predeterminedpercentage. If the first time slot is insufficient to cover allrequested on-site services, processing device 202 may arrange tasks in asecond time slot, keeping the first time slot under full availability ofthe field professionals.

FIG. 8B is a diagram of a timeline reflecting an example scheduleassociated with tasks, consistent with the present disclosure. In FIG.8B, two days of schedule are shown in the timeline. Five time slots areshown in FIG. 8B, in which time slot t1 spans from 8:00 to 16:00 in day1, time slot t2 spans from 16:00 to 20:00 in day 1, time slot t3 spansfrom 8:00 to 12:00 in day 2, time slot t4 spans from 12:00 to 16:00 inday 2, and time slot t5 spans from 16:00 to an undetermined time in day2. In day 1, processing device 202 may receive the set or requestsreflecting the current demand of the on-site service as described instep 802 in process 800A. Processing device 202 may predict imminentdemand for the same type of on-site service may rise in t3 based onhistorical data, as described at step 804. For example, the predictionmay show that during t3, some urgent requests of the same type ofon-site services would be made by customers, and such urgent requestshas high desirability to be completed soon (e.g., completed in t4).Processing device 202 may schedule a task associated with a fieldprofessional available to complete the on-site service in t4, asdescribed at step 806. To cope with the potential rise of imminentdemand, processing device 202 may reserve 20% of availability of fieldprofessionals in t4. That is, for all field professionals that may beassigned to complete the task in t4, the maximum percentage thereof tobe assigned in t4 is 80%. If the current demand of the on-site servicecannot be fully satisfied in t4, processing device 202 may startscheduling the task associated with field professionals available tocomplete the on-site service in t5. By doing so, if the urgent requestsoccur in t3, there would be 20% of field professionals available in t4to complete the tasks.

In some embodiments, processing device 202 may reserve availability inthe schedule for certain field professionals. In some embodiments,processing device 202 may reserve availability of field professionalswith a specific skill set, field professionals performing a specifictask type, field professionals having a specific experience level, orfield professionals conforming to any predetermined criteria. Forexample, referencing to FIG. 8B, the requests received at step 802reflecting the current demands may require a first skill and a secondskill. Two types of field professionals having the respective skills maybe assigned to complete the tasks. The imminent demands predicted atstep 804 may show that another service demand requiting the first skillmay rise in t3 but no service demand requiring the second skill wouldrise in t3, based on historical data. In this circumstance, processingdevice 202 may only reserve availability of field professionals havingthe first skill in t4, and impose no restriction on assigning fieldprofessionals having the second skill in t4.

In some embodiments, processing device 202 may reserve availability in aschedule for specific task types. For example, referencing to FIG. 8B,the requests received at step 802 reflecting the current demands mayinclude a first type of on-site service and a second type of on-siteservice. The imminent demands predicted at step 804 may show that onlythe first type of on-site service may rise in t3 based on historicaldata. In this circumstance, processing device 202 may only reserveavailability of field professionals performing the first type of on-siteservice in t4, and impose no restriction on assigning fieldprofessionals performing the second type of on-site service in t4. Insome embodiments, the percentage (e.g., 80%) of the reservedavailability may be determined based on a desired scheduling weight ofthe task, the details of which are described above.

In some embodiments, processing device 202 may identify service zonesassociated with the predicted demand. Processing device 202 may furtherreserve availability in a schedule of a field professional who travelsto an area associated with the identified service zones. A service zonemay be a geographic region where a field professional provides on-siteservice. The area associated with the service zone may be a geographicregion that includes, overlaps with, borders on, or locates close to theservice zone. In some embodiments, the service zone may be a zone thatincludes sites, buildings, or addresses that are easy to access inbetween, such as a university campus, a hospital campus, a residentialcommunity, or a business district. The service zone may be predeterminedand recorded as a data entry in database 154. In some embodiments, oneor more field professionals may be associated with a specific servicezone and provide on-site service in that specific service zone. In someembodiments, a field professional may be associated with one or moreservice zones for providing on-site services. Such associations may alsobe recorded or stored as data entries in database 154. In someembodiments, when a demand is predicted, processing device 202 may usean address of the predicted demand to identify a service zone where theaddress is in.

FIG. 8C is a diagram of a map showing example service zones associatedwith on-site services, consistent with the present disclosure. FIG. 8Cshows a base B of field professionals, four service zones S1-S4, a fieldprofessional P1 located near S1, illustrated as a round dot, and a fieldprofessional P2 located near S2, illustrated as a square dot. The base Bmay be the starting point (e.g., starting points in FIGS. 3A-3B) ofroutes of field professionals traveling to destinations for providingon-site services. For example, a demand is predicted to occur at anaddress in service zone S1. Processing device 202 may use the address toidentify S1 as the service zone. Processing device 202 may determinethat P1 is traveling to an area associated with S1. Processing device202 may then reserve P1's availability in P1's schedule. For example,processing device 202 may determine a probability that a demand willoccur in S1 and a distance from P1's current location to S1. Based onthe probability and the distance, processing device 202 may determinehow much availability would be reserved for P1. For example, the higherthe probability, the higher availability may be reserved. For anotherexample, the shorter the distance, the higher availability may bereserved.

In some embodiments, processing device 202 may identify a first servicezone associated with a first predicted demand and a second service zoneassociated with a second predicted demand lower than the first predicteddemand. For example, in FIG. 8C, processing device 202 may identify S1associated with a first predicted demand (e.g., a repairing service) andS2 associated with a second predicted demand (e.g., an installingservice). The second predicted demand may have a lower probability tooccur than the first predicted demand.

In the above embodiments, when the second service zone is more remotethan the first service zone, processing device 202 may determine astrategy for reserving availability of field professionals. In someembodiments, processing device 202 may avoid reserving availability in aschedule of a field professional traveling to an area associated withthe first service zone, and reserve availability in a schedule of afield professional traveling to an area associated with the secondservice zone. For example, in FIG. 8C, for field professional P1, S2 ismore remote than S1. Based on the distance between P1 and S1, thedistance between P2 and S2, and the probabilities that a demand willoccur in S1 and S2, respectively, processing device 202 may determinethe strategy for reserving availability of P1 and P2. For example, itmay take P1 10 minutes to travel to S1 and one hour to travel to S2. Inthis example, processing device 202 may avoid reserving P1'savailability in P1's schedule, and reserve P2's availability in P2'sschedule instead, even though the probability that a demand will occurin S2 is lower than the probability that a demand will occur in S1.

In some embodiments, after reserving in the schedule the availabilitybased on the predicted demand for the on-site services, processingdevice 202 may further determine tools and spare parts required in tasksassociated with predicted imminent demand. For example, in FIG. 8C,after reserving P1's availability in P1's schedule of t4 based on aprediction that an imminent demand (e.g., a repairing service) foron-site service in t4 might be requested in t3, processing device 202may determine required tools and spare parts for the imminent demand.Corresponding relationships between services and tools and parts may bestored as data entries in database 154. In some embodiments, once theimminent demand is predicted, processing device 202 may inquire database154 to determine the corresponding required tools and spare parts.

After determining tools and spare parts required in the tasks associatedwith the predicted imminent demand, processing device 202 may furtherconfirm that the set of field professionals assigned to tasks associatedwith the current demand will have the tools and spare parts required intasks associated with predicted imminent demand. For example, in FIG.8D, when P1 is traveling in the area associated with S1 to performon-site services requested in a current demand, processing device maydetermine that an imminent demand may occur in S1 and the required toolsand spare parts needed for the imminent demand in S1. Processing device202 may further confirm that P1 will have the required tools and spareparts for performing the imminent demand, in case P1 can be assigned tothe imminent demand when it actually occurs. In some embodiments, toconfirm so, processing device 202 may notify (e.g., by sending amessage) P1 the imminent demand that P1 may be assigned to and therequired tools and spare parts, and P1 may respond (e.g., by sendinganother message) to the notification to confirm whether P1 has thosetools and spare parts.

FIG. 8D is a flowchart of an example process 800D for scheduling tasksto field professionals, consistent with the present disclosure. In someembodiments, server 152 may implement process 800D. For example,processing device 202 may receive data from I/O system 210 or networkinterface 206, and then execute instructions or program codes stored inmemory interface 204 or database 154, in which the instructions orprogram codes implement algorithms of process 800D. The algorithms ofprocess 800D may be implemented as one or more of analysis module 441,forecasting module 442, planning module 443, or scheduling module 444.Process 800D includes the following steps or operations.

Process 800D starts with step 802 as described in FIG. 8A. At step 810,processing device 202 uses the historical data to identify eventsassociated with irregular past demand for field professionals. In someembodiments, the historical data may be data associated with pastservices and may include statistics of numbers and types of demandedon-site services. Based on frequencies of past demanded on-siteservices, processing device 202 may determine a frequency for each typeof demanded on-site services, and such frequency may be used todetermine a probability for each type of the on-site services to bedemanded. Such frequencies may be zone-specific or period-specific. Forexample, the frequencies may be calculated for each service zone (e.g.,as shown in FIG. 8C), for each hour of the day, or for each hour of thedate in each service zone. Based on the statistics, processing device202 may determine regular or irregular past demands. For example, if theprobability of a type of on-site service is in a predeterminedprobability range (e.g., 40% to 60%), processing device 202 maydetermine that on-site service as regular. If the probability of a typeof an on-site service is out of the predetermined probability range(e.g., lower than 40% or higher than 60%), processing device 202 maydetermine that on-site service as irregular.

In some embodiments, when processing device 202 identifies irregularpast demands, it may further determine whether an event is associatedwith those irregular past demands. For example, processing device 202may obtain from an information source to search for the event. The eventmay be a traffic condition, a weather condition, a specific time period,or a public event (e.g., a road construction, a road closure, a roadopening, a holiday, a big sports event, a concert, a big conference, aproduct promotion, a sales marketing event, etc.). For example,processing device 202 may identify that after a big snowstorm, pastdemands of utility repairing services may be irregularly high. Foranother example, processing device 202 may identify that before aholiday, past demands of Internet installing services may be irregularlyhigh.

At step 812, processing device 202 predicts event-related demand foron-site services based on the irregular past demand. For example, atstep 810, processing device may identify that, for a specific servicezone (e.g., S3 in FIG. 8D) in a specific time period of a day (e.g., t4in FIG. 8C), a regular probability of a repairing service is 40%, butthe probability thereof raises to 75% if a big snow storm happens beforethe specific time period. In this example, processing device 202 maypredict the event-related demand (i.e., related to the big snowstorm)for the repairing service to be 35%. In other words, the differencebetween the regular probability and the irregular probability reflectsthe demands caused by the big snowstorm.

After step 812, process 800D proceeds to step 806 as described in FIG.8A. At step 814, processing device 202 reserves in the scheduleavailability based on the predict event-related demand for on-siteservices. In the example set forth at step 810, when processing device202 determines that the storm-related demand for the repairing serviceis 35% at step 812, it may reserve a percentage of availability for afield professional serving the specific service zone in the specifictime period, if a big snow storm is predicted to happen before thespecific time period. The percentage may be determined based on theevent-related demand, such as 35%, 20%, or any other percentage thatreflect the influence of the event.

FIG. 8E is a flowchart of an example process 800E for scheduling tasksto field professionals, consistent with the present disclosure. In someembodiments, server 152 may implement process 800E. For example,processing device 202 may receive data from I/O system 210 or networkinterface 206, and then execute instructions or program codes stored inmemory interface 204 or database 154, in which the instructions orprogram codes implement algorithms of process 800E. The algorithms ofprocess 800E may be implemented as one or more of analysis module 441,forecasting module 442, planning module 443, or scheduling module 444.Process 800E includes the following steps or operations.

Process 800E starts with step 802 as described in FIG. 8A. In someembodiments, a memory (e.g., database 154 or memory interface 204) maybe configured to store historical data associated with past demand forfield professionals in a geographical area. The historical data may bedata associated with past performed services and may reflect statisticsof the past demand, the field professionals performing tasks associatedwith the past demands, and environments or circumstances when thosetasks were performed. The geographical area may be a region where fieldprofessionals 110 provide their services, such as the map in FIG. 8C.

In some embodiments, the memory may be configured to store historicaltraffic data in a geographical area. The traffic data is set forth indescription related to step 802 in FIG. 8A. The historical traffic datamay be traffic data associated with past demands. For example, thehistorical traffic data of service zones S1-S4 as shown in FIG. 8C maybe stored in database 154 and accessed via memory interface 204. In someembodiments, processing device 202 may be configured to determine dailyschedules of tasks based on the historical traffic data. Processingdevice 202 may determine the daily schedules of tasks based on thehistorical traffic data in a way similar to some embodiments of step 806as described.

In some embodiments, the memory may be further configured to storehistorical performance data of the field professionals. Performance datamay be data reflecting performances of the field professionals, such astime spent on completing the services, time spent on traveling, numbersof completed tasks in a workday, number of total working hours, reviewsfrom customers, efficiency of completing the tasks, etc. The historicalperformance data of the field professionals may be their performancedata associated with past demands. Processing device 202 may be furtherconfigured to determine the daily schedules of tasks based on thehistorical performance data. For example, based on the historicalperformance data, processing device 202 may rank the field professionalsaccording to customers' feedback on their past performances (e.g., byreview scores). Based on the ranking, processing device 202 maydetermine daily schedules of tasks for the field professionals, such asassigning more tasks to field professionals with higher rankings thanfield professionals with lower rankings.

In some embodiments, the set of requests may be associated with a numberof task types and each request may be associated with a differentlocation. For example, processing device may receive multiple requestsat step 802, each of which may be associated with a task type (e.g.,repairing, installing, replacing, maintaining, inspecting, etc.). Eachof the requests may also be associated with a different location (e.g.,in service zones S1-S4 in FIG. 8C).

In some embodiments, processing device 202 may receive environmentaldata indicative of future events that can affect certain locations inthe geographical area. For example, the environmental data may bereceived from different data sources outside system 100 that monitor theenvironmental conditions in areas associated with task locations. Theenvironmental data may include information reflecting a known futureevent, such as a scheduled power blackout, infrastructure maintenance(e.g., a road construction work), an atypical weather condition, apublic event (e.g., a parade), or the like. The future events may affectsome locations in the geographical area where the historical datathereof is stored in the memory.

At step 816, processing device 202 uses the historical data to identifyservice zones in the geographical area associated with predicted demandfor specific task types. In some embodiments, the predicted demand maybe the imminent demand determined at step 804 in process 800A. Thepredicted demand may be associated with multiple task types (e.g.,repairing, installing, replacing, maintaining, inspecting, etc.). Thepredicted demand may also be associated with on-site services atdifferent locations. Processing device 202 may identify the servicezones based on the locations. For example, the service zones may beS1-S4 in FIG. 8C.

In some embodiments, if processing device 202 receives the environmentaldata at step 802, processing device 202 may identify the service zonesin the geographical area further based on the environmental data. Forexample, the environmental data may indicate that a snowstorm will occurin the geographical area and some service zones will be affected. Theaffected service zones may have higher demand of some task types (e.g.,repairing). Based on such environmental data, processing device 202 mayidentify the service zones that might have higher demands due to thecoming snowstorm.

At step 818, based on the requests, processing device 202 determines aset of daily schedules of tasks for a set of field professionals. Step818 may be implemented in a way similar to step 806 in process 800A. Insome embodiments, processing device 202 may reserve capacity to accountfor predicted demand for a certain daily schedule with a task associatedwith a location in proximity to an identified service zone. The capacitymay reflect the capability and resources available to complete therequested on-site services. For example, the capacity may includeavailability of field professionals, tools, spare parts, vehicles, etc.In one embodiment, processing device 202 may predict that the likelihoodof a task in that area is greater than a threshold, accordingly, a fieldprofessional may be sent to an identified service zone even if there isno pending task or a scheduled service in that area.

In some embodiments, processing device 202 may determine the schedulefor the field professionals under full capacity. For example,referencing to FIG. 8C, service zones S3 and S4 may be identified atstep 816 where some demands having the specific task types are predictedto occur. Processing device 202 may reserve availability of fieldprofessional P1 who has a schedule to complete a task in a locationproximate to S1 to account for the predicted demand. In other words, inanticipation that predicted demand in S1 will be requested, processingdevice 202 may reserve P1's availability in case those predicted demandsare actually requested in S1, in which processing device 202 may assignP1 to respond to the predicted demands. In some embodiments, besidesavailability of field professionals, processing device 202 may furtherreserve other capacity or resources in anticipation of responding to thepredicted demands, such as extra tools, spare parts, vehicles, etc.

At step 820, using network interface 206, processing device 202 providesdirectional instructions to a field professional assigned to the certaindaily schedule to a location in proximity to a service zone. Forexample, referencing to FIG. 8C, field professional P2 is assigned to adaily schedule to perform a task at a location proximate to S2 wheredemands in S2 are predicted to occur in the future. Processing device202 may provide directional instructions to P2 using network interface206. In some embodiments, P2 may receive the directional instructionsvia communication device 180A. In some embodiments, P2's vehicle (e.g.,an autonomous vehicle) may receive the directional instructionsautomatically without P2's intervention. The directional instructionsmay be instructions that are informative for the field professional tocomplete tasks associated with the predicted demands.

In some embodiments, the directional instructions to the location inproximity to the service zone may include at least one of a waypoint, anaddress, and a driving route. For example, referencing to the example atstep 820, the driving route may be a calculated route for P2 to drive toan address of a decimation in S2 where a predicted demand is actuallyrequested, and the waypoint may be a location in the driving route.

In some embodiments, processing device 202 may assign a specific fieldprofessional to the certain daily schedule based on the predicted demandfor specific task types in the identified service zone and knowncapabilities of the specific field professional. In some embodiments,the specific field professional may have a higher qualification or awider range of skills than a normal field professional. For example,referencing to FIG. 8C, some demands having the specific task types(e.g., inspecting and installing) may be predicted to occur in S2 atstep 816. P2 may be known to have capabilities to perform tasks ofinspecting and installing. Another field professional P3 (not shown) whois near P2 may be known to have capabilities to perform tasks ofinstalling only. Based on such information, processing device 202 mayassign to P2 the daily schedule of completing tasks at a locationproximate to S2 in case the predicted demands having inspecting andinstalling services are actually requested. Such assignment may achievea goal that, when the predicted demands are actually requested, P2 mayrespond to a wider range of tasks than P3.

In some embodiments, processing device 202 may confirm that the fieldprofessional assigned to the certain daily schedule is capable toprovide the specific task type in the identified service zone. In someembodiments, referencing to the previous example, processing device 202may assign P2 daily schedule of completing tasks at a location proximateto S2. To confirm that P2 is capable to provide the inspecting andinstalling service types in S2, processing device 202 may inquire (e.g.,by sending a message) P2 whether P2 has the capability to complete theinspecting and installing service in S2. In some embodiments, processingdevice 202 may further inquire P2 whether P2 has required tools andspare parts for the inspecting and installing service in S2. P2 mayrespond (e.g., by sending another message) to the inquiry to confirm.

In some embodiments, when a daily schedule of another field professionalhas unexpectedly become available, processing device 202 may beconfigured to direct the another field professional to an identifiedservice zone even when no specific request from locations in proximityto the identified service zone has been received. For example,referencing to FIG. 8C, a third field professional P3 (not shown) mayunexpectedly become available, such as due to canceled requested demandsin P3's daily schedule. In this example, processing device 202 may haveidentify S1 and S2 as service zones that might have predicted demands atstep 816. Processing device 202 may then direct P3 to S2 (or S1), evenat a time when processing device 202 does not receive any specificrequest for on-site services at locations proximate to S2 (or S1). Bydoing so, when the predicted demands in S2 (or S1) are actuallyrequested, more field professionals will be available to be assigned tothe predicted demands, and the travel time for the assigned fieldprofessional (e.g., P3) may be shortened.

In some embodiments, processing device 202 may assign at least onelocation-agnostic task to the field professional to fill the reservedcapacity when no additional on-site tasks are scheduled in the servicezone. The location-agnostic task is a task that the field professionalcan perform remotely from a customer's place, such as a technicalsupport session (e.g., a call, a video chat, an online chat, etc.). Forexample, referencing to FIG. 8C, when no additional on-site tasks arescheduled in S2 (e.g., the predicted demands in S2 are not actuallyrequested), P2 may become idle because processing device 202 maypreviously reserve P2's availability. To fill P2's reservedavailability, processing device 202 may assign the location-agnostictask to P2, such that P2 may be utilized.

D. Scheduling Tasks

Disclosed and claimed is a system that may implement task scheduling forfield professionals to complete a service in a single visit (referred toas “first-time technical services”) by determining requirements forcompleting the service based on comparison of attributes of services.The system may receive a request for a service, determine at least oneattribute of the requested service, and compare the determined attributeto other services to determine a requirement for completing the servicein a single visit. The at least one attribute may include, for example,information on the equipment, information on the infrastructure,information on the residence, information on environmental conditions,or any other information needed to perform the service. The requirementmay include, for example, tools, spare parts, qualifications, vehicles,or any other physical object or precondition needed to perform theservice. In some embodiments, the system may be implemented as taskscheduling unit 150.

FIG. 9A is a flowchart of an example process 900A for schedulingfirst-time fix services, consistent with the present disclosure. In someembodiments, server 152 may implement process 900A. For example,processing device 202 may receive data from I/O system 210 or networkinterface 206, and then execute instructions or program codes stored inmemory interface 204 or database 154, in which the instructions orprogram codes implement algorithms of process 900A. The algorithms ofprocess 900A may be implemented as one or more of analysis module 441,forecasting module 442, planning module 443, or scheduling module 444.Process 900A includes the following steps or operations.

At step 902, processing device 202 stores a plurality of recordsreflecting characteristics associated with completing a set of technicalservices in database 154. The technical services may include anycombination of any number of on-site services or remote services. Forexample, the on-site services may include any of installing, replacing,repairing, or inspecting products or services of any of water, sewage,electricity, gas, heat, Internet, telephone, mobile communications, orthe like. The remote services may include any of telephone calls, videochats, text messages, mobile application communications, or any othertechnical or support services that may provide answers to a customer'squestions or instructions to solve a problem.

In some embodiments, the characteristics may include any combination ofany number of attributes, requirements, details, statistics, feedbacks,or any information that are associated with completing the set of thetechnical services. For example, the characteristics may include anycombination of any number of a specific tool, a spare part, a vehicle, aqualification of a field professional, a specific back-end service(e.g., an internal communication line between the field professional andserver 152), or any physical object or requirements associated withcompleting a service.

In some embodiments, the records may be implemented as database entriesin database 154. For example, in those database entries, relationshipsbetween the characteristics and the technical services may be stored asrelational database entries. In some embodiments, information in eachrecord may be derived from historical experience of completing each ofthe technical services. The information in a record may be implementedas a portion of a database record, such as an attribute of a relationaldatabase record in database 154. The historical experience may includeany data reflecting statistics, performance records, customer reviews,customer feedbacks, comments, scores, or any previously stored datarelated to completing the technical services. Consistent with thepresent disclosure, the information in each record may be derived byusing machine learning algorithms that identify patterns in the recordsof completed tasks. For example, the patterns may be indicative of skillsets of field professionals that have completed certain tasks in asingle visit. In some embodiments, each services may include datareflecting multiple services completed by multiple field professionals.

In some embodiments, the information in each record may be derived fromthe historical experience using a statistical technique. For example,when the historical experience includes quantified data (e.g., scores,statistics, or the like), the derived information may include astatistic value of the information, such as an average score, an averagevalue, a standard error, or the like. For example, when the historicalexperience includes a customer review score, the derived information maybe an average review score. For another example, when the historicalexperience includes multiple time periods for completing the service,the derived information may be an average completion time for theservice and an estimated fluctuation range determined based on astandard error of the multiple time periods.

In some embodiments, when the historical experience includesnon-quantified data, the information may be derived using a synthesistechnique. For example, when the historical experience includes textualdata (e.g., textual comments, summaries, memoranda, or the like), theinformation of the records may be key elements of the textual dataderived using a natural language processing technique. For anotherexample, when the historical experience includes textual data, theinformation may be derived as an aggregation of the textual data. Theaggregation of the textual data may include, for example, simpleaggregation (e.g., concatenating) of the textual data, or merging (e.g.,by removing duplicate fields) of the textual data.

In some embodiments, the information in the records may be derived fromfeedback from a set of field professionals (such as field professionals110). For example, when a field professional did not complete a servicein a single visit, the field professional may provide feedbackexplaining one or more reasons why he or she could not complete theservice in a single visit. The feedback may include quantized ornon-quantized data. For example, the feedback may be textual commentsdrafted by the field professionals, such as via a graphical userinterface (GUI) of communication device 180A. For another example, thefield professional may be provided a list of selections to identify thereason why he or she could not complete the service in a single visit(e.g., via the GUI of communication device 180A), and the feedback maybe the item selected by the field professional. For another example,each reason why the service cannot be completed in a single visit may bepre-assigned with a code, and the feedback may include the code providedby the field professional (e.g., via the GUI of communication device180A).

In some embodiments, the derived information may also be stored asdatabase entries in database 154. In some embodiments, the derivedinformation may be stored as separate data entries from the plurality ofrecords. In some embodiments, the derived information may be integratedinto the plurality of records, such as additional attributes of thedatabase entries of the records.

Referring back to FIG. 9A, at step 904, processing device 202 receives arequest for a new technical service associated with a location. In someembodiments, processing device 202 may receive the request may via thenetwork interface 206. The request may be sent from communication device180C by a customer, or sent from customer service unit 120. The newtechnical service may be one of the set of the technical services atstep 902.

At step 904, processing device 202 assigns a field professional toperform the new service when processing device 202 has determined frominformation in the database a likelihood that the field professionalwill complete the new technical service in a single on-site visit at thelocation. In some embodiments, processing device 202 may determine thelikelihood from the derived information at step 902. The likelihood maybe determined using multiple techniques.

In one embodiment, processing device 202 may determine the likelihoodusing a statistical technique. For example, by statistics of thecharacteristics associated with completing the new service andstatistics of completing the same type of service under the same orsimilar characteristics by the field professional, processing device 202may determine a likelihood based on a calculation of the two statistics.For example, when the statistics of the characteristics show that anaverage completion time for the type of the new service is 60 minutes,and the statistics of the field professional show that his or her anaverage time for the type of the new service is 50 minutes, processingdevice 202 may determine a likelihood that the field professional willcomplete the task within 60 minutes with a predetermined confidencelevel (e.g., 95%).

In another embodiment, processing device 202 may determine thelikelihood using a machine learning mode. For example, a neural networkmodel (e.g., a deep learning model) may be created and set with initialparameters. Based on statistics of the field professional completing thetype of the new service, locations, and characteristics of the technicalservice under which the field professional completed the same type ofthe new service, the neural network model may be trained, and theinitial parameters may be updated. Using the trained neural networkmodel, by inputting the characteristics of the same type of thetechnical service, the location of the technical service, and the nameof the field professional, the trained neural network may output alikelihood that the field professional will complete the technicalservice in a single on-site visit at the location.

In some embodiments, processing device 202 may prioritize customersatisfaction by assigning a field professional having a higherlikelihood to complete the customer's request of service in a singlevisit. For example, processing device 202 may determine a firstlikelihood that a first field professional will complete the newtechnical service in a single on-site visit at the location. Processingdevice 202 may determine a second likelihood that a second fieldprofessional will complete the new technical service in a single on-sitevisit at the location, and the second likelihood is greater than thefirst likelihood. Processing device 202 may then assign the second fieldprofessional to perform the new service.

In some embodiments, the information derived from the plurality ofrecords at step 902 may include information obtained from one or moredetails associated with completing the requested service. The detailsmay include customer inputs, logistics information, reminders, practicetips, check lists, key instructions, guidelines, or any informativematerial that would assist completing the requested service or gettingthe field professional prepared. In some embodiments, if the fieldprofessional knows the detail prior to performing the service, his orher likelihood to complete the requested service in a single on-sitevisit may increase.

In some embodiments, processing device 202 may further identify at leastone detail from the plurality of records. Upon receiving the request forthe new technical service, processing device 202 may obtain informationassociated with the at least one detail. In some embodiments, the detailmay be stored as separate data entries from the plurality of records. Insome embodiments, the details may be integrated into the plurality ofrecords, such as additional attributes of the database entries of therecords.

In some embodiments, processing device 202 may obtain informationassociated with the at least one detail by retrieving information aboutthe location associated with the new technical service from at least onedatabase (e.g., database 154). For example, the information about thelocation may include the type of infrastructure in the area, such aswater, sewage, electricity, gas, heat, Internet, telephone, mobilecommunications, or the like.

In some embodiments, processing device 202 may obtain informationassociated with the at least one detail by enquiring a user associatedwith the request. For example, if the technical service involves aproblem with water supply, processing device 202 may send a request fordetail to the user, asking the user if the location of the service hasaccess to a water stopcock. For another example, if the technicalservice involves a problem with Internet connection, processing device202 may send a request for detail to the user, asking the user if theuser has a working modem. For another example, if the technical serviceinvolves a problem with electricity, processing device 202 may send arequest for detail to the user, asking the user if the user has anactive account with the utility provider.

At step 906, processing device 202 may assign field professional toperform the new service further based on the obtained informationassociated with the at least one detail. For example, the detail mayinclude a type of infrastructure in the location of the service, andworking on the type of infrastructure may require a specificqualification (e.g., a certificate of electrician). Processing device202 may inquire database 154 to obtain only the field professionals withthe specific qualification, and assign the field professional among themto perform the new service. In some embodiments, processing device 202may further identify from the plurality of records a set of attributesfor completing performance the new technical service in a single on-sitevisit. The set of attributes may include, for example, information onthe equipment, information on the infrastructure, information on theresidence, information on environmental conditions, or any otherinformation needed to perform the service.

At step 908, processing device 202 may receive information that mayaffect the likelihood of the assigned field professional to complete thecustomer's request of service in a single visit. The information mayinclude real-time information about a condition of object associatedwith the scheduled service, or the current status of parts (e.g., tools)that the field professional has currently available in his/herinventory. For example, the field professional may be a nurse scheduledto do a home visit to do dialysis and the information may includeupdates on a health condition of a patient. The information may bereceived in response to an enquiry triggered by processing device 202 orindependently by the customer.

At step 910, processing device 202 may determine if, in view of thereceived information, the likelihood of the assigned field professionalto complete the customer's request of service in a single visit is stillgreater from a threshold. Step 910 may take place after the fieldprofessional was assigned and before the date and time that the task isscheduled for. For example, the information may be received on the sameday as the scheduled task. Alternatively, the information may bereceived one or more days before the scheduled task. When the likelihoodis below the threshold, processing device 202 may assign a differentfield professional with higher likelihood to complete the customer'srequest of service in a single visit. When the likelihood is greater thethreshold, processing device 202 may continue with the same fieldprofessional and wait for additional information that may change thelikelihood.

FIG. 9B is a flowchart of an example process 900B for schedulingfirst-time fix services, consistent with the present disclosure. In someembodiments, server 152 may implement process 900B. For example,processing device 202 may receive data from I/O system 210 or networkinterface 206, and then execute instructions or program codes stored inmemory interface 204 or database 154, in which the instructions orprogram codes implement algorithms of process 900B. The algorithms ofprocess 900B may be implemented as one or more of analysis module 441,forecasting module 442, planning module 443, or scheduling module 444.Process 900B includes the following steps or operations.

At step 920, processing device 202 receives a request for an on-siteservice at a selected location. Step 920 may be implemented in a similarway to step 904. At step 922, processing device 202 identifies a set ofattributes associated with the requested on-site service. The set ofattributes may include, for example, information on the equipment,information on the infrastructure, information on the residence,information on environmental conditions, or any other information neededto perform the service.

In some embodiments, processing device 202 may identify the set ofattributes based on the location associated with the on-site technicalservice. For example, based on the location, processing device mayinquire database 154 for any information about the address of thelocation, the infrastructure associated with the location, the currentenvironmental conditions (e.g., weather conditions or trafficconditions) near the location, the equipment available to be used at thelocation, or the like. In some embodiments, the set of attributes mayinclude information about a residence of a user associated with therequest. For example, different residences may need different equipmentto complete the requested services, and based on the residence of theuser, processing device 202 may determine the information about theequipment available to be used at the residence.

In some embodiments, processing device 202 may determine the set ofattributes based on retrieved information about a user associated withthe request. In some embodiments, the information about the user may bestored in database 154 and retrievable using the received request. Forexample, the request may include a name, an address, a phone number, anemail address, or any identification information of the user. Using thatidentification of the user, processing device 202 may retrieve theinformation about the user from database 154. The information about theuser may be any informative data associated with the user, such as anage, a gender, a job title, a block-out on-site visit time, a block-outdate, or any other data related to the person. In some embodiments, theset of attributes may include information about an age of the user. Forexample, when the requested service involves a problem with theInternet, a user in a specific age range (e.g., a very young age or avery old age) might have a higher likelihood of misdescribing theproblem or misidentifying the cause of the problem. Based on theinformation about the age of the user, the field professional may have awarning to look for other possible problems or causes, which may help tocomplete the on-site service in a single visit.

In some embodiments, processing device 202 may determine the set ofattributes based on a type of service requested. For example, the typeof services requested may include installing, replacing, repairing, orinspecting products or services. In some embodiments, the set ofattributes may include information about tools and spare parts needed toperform the type of service requested. For example, if the type of theservice requested is installing a new device, the attributes may includeinformation about the new device. If the type of the service requestedis repairing a device, the attributes may include information abouttools and spare parts for repairing the device.

In some embodiments, processing device 202 may determine the set ofattributes based on environmental data. In some embodiments, theenvironmental data may be data representing a condition near thelocation of the requested device or along a route to the location. Forexample, the environmental data may include data representing a weathercondition, a traffic condition, a public event (e.g., a scheduled roadclose), or any other condition that might affect the performing of therequested service. In some embodiments, the set of attributes mayinclude information about predicted weather conditions at the time ofproviding the service. For example, when the requested service requiresworking outside, and if a storm is coming at the time of providing theservice near the location of the service, processing device 202 mayschedule the service to another time. For another example, when therequested service requires travelling to a remote residence during peakhours and is highly likely to miss the requested time, processing device202 may suggest the user to schedule the service to another time. Insome embodiments, the set of attributes may include information aboutpredicted light conditions at the time of providing the service. Forexample, when the requested service requires working outside and thetime of providing the service is after dawn, processing device 202 mayindicate a field professional assigned at step 926 to bring additionaltools for lighting.

Referring back to FIG. 9B, at step 924, processing device 202 uses theinformation stored in a memory (e.g., database 154) and the set ofattributes to identify at least one requirement for completing theon-site service in a single visit. The requirement may include, forexample, tools, spare parts, qualifications, vehicles, or any otherphysical object or precondition needed to perform the service. At step926, processing device 202 assigns a field professional to a task ofproviding the on-site service. In some embodiments, the assignment maysatisfy the identified at least one requirement. For example, when theattributes identified at step 922 include a required specificqualification to provide the on-site service, the assigned fieldprofessional may have the specific qualification. For another example,when the attributes identified at step 922 requires a specific equipment(e.g., a special lifter vehicle), the assigned field professional may beone that can operate the specific equipment.

At step 928, processing device 202 provides, using network interface206, information for directing the field professional to the selectedlocation. For example, when the attributes of the identified at step 922include a residence that requires a specific equipment, the assignedfield professional may be provided with information to bring thespecific equipment. For another example, when the attributes of theidentified at step 922 include an age of the user which falls into aspecific range, the assigned field professional may be indicated toconsider other possible problems or causes of problems. For anotherexample, when the attributes of the identified at step 922 include aweather condition not suitable for outside work, the assigned fieldprofessional may be indicated to be rescheduled to another time.

E. Identifying Causes for Unscheduled Tasks

Services provided by field professionals often have required responsetimes set by task urgency or customer priority. It may be difficult,however, to respond to the requests within the expected response time.This can occur, for instance, if a task must be completed within a weekof a customer making a request, but the field professional who iscapable of performing the task is on vacation for a month. The followingdisclosure describes methods and systems for implementing anoptimization dashboard that determines causes of unscheduled tasks offield professionals, enabling a reduction in the number of futureunscheduled tasks. The system includes a memory, a network interface,and a processor connectable to the network interface. When schedulingtasks to field professionals, each task may be associated withconstraints, such as the duration of a task, work hours, traveldistance, and field professional skillset. The system may identify aplurality of tasks that were not scheduled within a predefined periodand determine a common cause for them not to be scheduled within thepredefined period. Thereafter, the system may present a recommendationfor reducing the number of future unscheduled tasks. The recommendationmay include, for example, changing a task constraint or hiringadditional field professionals.

FIG. 10 is a diagram illustrating a scheduling engine 1010 that receivesrequests and schedules corresponding tasks. The scheduling engine 1010may, for example, be implemented using the task scheduling unit 150.Scheduling engine 1010 may be implemented in hardware, software, or acombination of both. FIG. 10 illustrates a plurality of requests,Request 1-Request i. Some requests, such as Request 1-Request 5, arefrom Date 1. Similarly, Request 6-Request 8 are from Date 2, Request 9and 10 are from Date 3, and Request i is from Date j. The schedulingengine 1010 processes the requests in relation to a variety ofconstraints, including distance, time, geographic, service, andfield-professional related constraints. After processing the requests,the scheduling engine 1010 schedules tasks in response to each of therequests. The tasks may be schedule within the expected period of timeor outside the expected period of time. For instance, Task 1-Task 3 andTask 5 are all expected to be completed within the period of time ofseven days. However, due to the constraints, Task 4 is expected to becompleted thirteen days after the request. Since this is longer thanseven days, the scheduling engine 1010 may identify Task 4 as it is notscheduled to be completed within the expected period of time. Similarly,while Task 9 is scheduled within two days of the corresponding request,Task 10 is scheduled eleven days after the corresponding request.Therefore, since at least two requests were not scheduled with tasksexpected to be completed within an expected period of time, adetermination is made of a common cause of why the expected period oftime was not satisfied. A person skilled in the art would recognize thatthe above example is simplified, and an actual scheduling engine mayinvolve substantially more requests, constraints, and tasks.

FIG. 11 is a flowchart of an example process 1100 for scheduling tasksto field professionals, consistent with the present disclosure. In someembodiments, server 152 may implement process 1100. For example,processing device 202 may receive data from I/O system 210 or networkinterface 206, and then execute instructions or program codes stored inmemory interface 204 or database 154, in which the instructions orprogram codes implement algorithms of process 1100. The algorithms ofprocess 1100 may be implemented as one or more of analysis module 441,forecasting module 442, planning module 443, or scheduling module 444.Process 1100 includes the following steps or operations.

At step 1102, processing device 202 receives, from the network interface206, a set of requests for services. The set of requests may be anynumber of requests and may originate from clients, managers, fieldprofessionals, or from an automated system. The services may include anycombination of any number of on-site services or remote services. Forexample, the on-site services may include any of installing, replacing,repairing, or inspecting products or services of any of water, sewage,electricity, gas, heat, Internet, telephone, mobile communications, orthe like. The remote services may include any of telephone calls, videochats, text messages, mobile application communications, or any othertechnical or support services that may provide answers to a customer'squestions or instructions to solve a problem.

At step 1104, processing device 202 schedules a set of tasks, inresponse to the set of requests for services. The processing device 202may also establish a period of time within which the task must beaccomplished. Some tasks may be expected to be completed within a periodof time from when a corresponding request was received. In other words,some tasks may need fast or slow response times, such that they need tobe completed quickly after receiving a request for service, or may bedelayable. Management may set the expected completion period based on avariety of factors, such as urgency of the request, availability ofresources, customer priority, or risk of additional damage. The periodof time may be a set time, such as 9:00 on Friday the 23rd, or it may bea time limit, such as within two hours of request receipt. Whenscheduling, the processing device 202 may establish the schedule basedon scheduling constraints. Scheduling constraints may be rules of when atask may or may not be scheduled. For instance, if a field professionalhaving a necessary skillset is on vacation until the end of the month,the processing device 202 may avoid scheduling a particular task whilethe professional is away. Alternatively, the scheduling constraints mayinclude work hours, holidays, part and equipment availability, traveltime, task duration, and the like.

At step 1106, processing device 202 determines a common cause of why atleast two requests were not scheduled within a corresponding expectedperiod of time. A common cause may be a reason, shared among multiplerequests, explaining why the requests were not scheduled within acertain period of time. For instance, if a request is received to repaira customer's cable television, and the task of repairing the cabletelevision is not scheduled to occur within a company's expected periodof time of two hours because all available field technicians werealready performing or scheduled to perform other tasks, processingdevice 202 may record the first occurrence of the unscheduled task.Should a similar situation occur again based on a second request,processing device 202 may identify the common cause as being not enoughfield professionals. Similarly, processing device 202 may identify acommon cause of insufficient replacement parts, database errors, vehiclemaintenance, and the like. Alternatively, processing device 202 mayidentify that the constraint is too limiting, such that a strictscheduling constraint should be relaxed. By identifying common causes oftasks not being scheduled within a period of time, processing device 202may, at step 1108, enable reducing the number of future unscheduledtasks.

In some embodiments, the set of requests may be received from aplurality of users. Furthermore, each of the requests may be associatedwith an on-site service to be provided in a different location. That is,many users 130 may make requests for field professional service bycontacting the customer service unit 120. Thus, the set of requests maycontain a service and a location where the service must be provided,enabling more accurate scheduling of tasks as well as knowledge ofscheduling constraints.

Scheduling constraints may include distance, time, geography, service,or field professional related constraints. As an example of distanceconstraints, a company may have a policy that its field professionalswill only travel to locations within three hours of travel during themorning hours, so as to reduce travel costs and burden on fieldprofessionals. Alternatively, scheduling may be constrained by time ofday considerations, such that tasks that typically take three hours tocomplete or tasks with a wide range of durations will not be schedulednear the end of a day. Furthermore, a company may prohibit its fieldprofessionals from traveling to certain high crime areas duringnighttime, thereby constraining the schedule. Services that requireheavy outdoor labor may be constrained to early morning or late eveningscheduling. Finally, a schedule may be limited by capabilities ofspecific field professionals. For instance, if a particular servicerequires a master plumber and Rob is the only master plumber employed bya company, scheduling of a service that requires a master plumber may beconstrained by Rob's vacation and work schedule.

Scheduling constraints may also include at least two of adistance-related constraint, a time-related constraint, ageographic-related constraint, a service-related constraint, and afield-professional-related constraint. For instance, a schedulingconstraint may be that certain field professional is only able tocomplete tasks within a two-hour travel radius of a main office.Alternatively, for example, a refinery requiring a pneumatic mechanicmay only be shut down for maintenance at night. In such a case, therewould be a time-related constraint as well as a service-relatedconstraint of a certain skill set.

The scheduling constraints may be inputted by a user. The user may be anadministrator of the system, who may use the I/O system 210 to inputscheduling constraints. The scheduling constraints may be entered alongwith the set of requests. Alternatively, the scheduling constraints maybe entered asynchronously from the set of requests, for example, beingsaved for use in scheduling a future set of tasks, or after receiving aset of requests for services.

Alternatively, scheduling constraints may be generated by an ArtificialIntelligence (AI) module. The AI module may be part of the schedulingmodule 444, or in a different system. The AI module may, for instance,determine scheduling constraints from past schedules, sets of requests,sets of tasks, or scheduling constraints. For instance, if only onefield professional is able to service elevators, and that one fieldprofessional is unable to work after noon on Fridays, the AI maydetermine that elevators may not be serviced on Friday afternoon. Asanother example, if no field professionals are able to keep appointmentsin the city after 4:00 due to traffic, the AI may create a schedulingconstraint that tasks will not be scheduled in the city after 4:00.

The set of requests may be associated with different task types. In thiscase, the processor may be configured to determine a period of time fortask completion for each request based on the associated task type. Forexample, in the case of a medical field professional, if a servicerequest of taking a blood sample is made, the medical field professionalmay be expected to complete this task within three days. However, if aservice request is made because a patient has the flu, the medical fieldprofessional may be expected to complete the task within one day. Thus,the processing device 202 would determine the period of time for taskcompletion for each of the requests in the set of requests. Furthermore,the processor may be configured to determine a common cause why a firstrequest associated with a first period of time and a second requestassociated with a second period of time longer than the first period oftime, were not scheduled with tasks expected to be completed withintheir corresponding periods of time. For example, if the medical fieldprofessional was unable to draw blood within three days, and also wasunable to treat the flu within one day, the system may determine thatneither request was scheduled within the expected period of time becausethe medical field professional was ill or on vacation. This could helpidentify if more medical field professionals are needed.

The system may determine a plurality of causes for the set of requests.A common cause may be associated with at least two of the schedulingconstraints. Each cause may be associated with a number of requests thatwere not scheduled with tasks expected to be completed withincorresponding periods of time. For example, requests that were notscheduled with tasks expected to be completed within the period of timemay have the same constraint that the requests require work done morethan a three-hour drive away. Furthermore, the requests may also havethe same constraint that work must be completed while a facility is shutdown for maintenance. Thus, the common cause may be associated with atleast two scheduling constraints. The processor may also identify a maincause of why some requests were not scheduled with tasks expected to becompleted within corresponding periods of time, and also cause anissuance of a notification associated with the main cause. For example,a main cause may be a constraint that is too restrictive and preventsscheduling a set of tasks unnecessarily. For instance, a constraint maybe that no tasks may be scheduled after 1:00, and no HVAC servicing maybe done without Mackenzie. Both of these constraints may lead to anumber of requests not having scheduled tasks expected to be completedwithin a corresponding expected period of time. The processor maytherefore determine that the constraint on no tasks being scheduledafter 1:00 is the main cause of why some requests were not scheduledwith tasks expected to be completed within the corresponding period oftime. The processor, therefore, may issue a notification alerting a userto the main cause. Alternatively, for example, the processor maydetermine that constraints inputted on January 7 are too restrictive,and notify a user of such a finding.

After determining a common cause of why at least two requests were notscheduled with tasks expected to be completed within the period of time,the processor may present a recommendation for reducing the number offuture unscheduled tasks. This recommendation may be displayed, forinstance, as part of the service optimization suite architecture shownin FIG. 5. The presentation layer 502 may display a recommendation. Forinstance, the presentation layer 502 may display a suggested schedulebased on the determined recommendation that has less unscheduled taskscompared to an existing schedule. The suggested schedule may cover anyperiod of time, such as a day, week, or month. This suggested schedulemay have different scheduling constraints than the original schedule.For example, the recommendation may include a suggestion to change atleast one of the scheduling constraints. That is, the recommendation maysuggest removing limitations on the length of a workday, driving range,or geographic area. Alternatively, the recommendation may be to moveconstraints in time. For example, the recommendation may be to constraintasks in a city to afternoon hours rather than morning hours, thusavoiding traffic. In some embodiments, the recommendation may include asuggestion to hire additional field professionals. If the systemdetermines that a particular field professional is frequently needed attwo facilities, many miles apart, and travel time causes constraints onthe field professional's ability to serve both sites, the system mayrecommend hiring an additional professional. Furthermore, if aparticular field professional has a unique skillset that others do not,the system may include a description of the qualifications needed fornew field professionals.

Additionally, the processor may also be configured to determine how manyof the requests would have been scheduled to tasks expected to becompleted within the predefined period of time if the recommendation hadbeen implemented before. When displayed, the recommendation may includea metric showing the reduction in unscheduled tasks. The number ofrequests that would have been scheduled to tasks may be calculated onpast, present, or future schedules. Furthermore, the number of requestsmay be calculated for any defined period of time, such as a month.

FIG. 12 is a flowchart of a process 1200 for initiating an action due tounscheduled tasks. At step 1202, the system receives a request for aservice and, at step 1204, the system schedules a task based onscheduling constraints. At step 1206, the system determines if the taskwas scheduled within the expected period of time. If step 1206 is Yes,the system waits to receive the next request for a service. If step 1206is No, the system stores details of the request at step 1208. The systemthereby determines the number of requests that were not scheduled withtasks expected to be completed within the period of time. At step 1210,the system determines if there are more than two unscheduled tasks. Dataused in this determination may be stored in the database 154. The numberof requests may cover any period of time. Furthermore, the period oftime may be in the past, or the period of time may be in the future,such that the number of requests not scheduled may be analyzed andpotentially corrected before the period of time elapses. For instance,if a schedule for the next week has already been set, the number ofrequests that were not scheduled with tasks expected to be completed maystill be calculated, thus giving a manager the opportunity to reshapethe schedule to avoid or reduce unscheduled tasks and better servecustomers. If step 1210 is Yes, the system may proceed to step 1212 todetermine a common cause of the unscheduled tasks. If step 1210 is No,the system may proceed to step 1214 without determining a common cause.

The system may also initiate an action when the determined number ofrequests is greater than a predetermined threshold. For example, acompany may set a threshold of five unscheduled tasks for a month. Atstep 1214, the system determines if the number of unscheduled tasks isgreater than the threshold. If step 1214 is No, the system returns towait for the next request. However, if step 1214 is Yes, the system mayinitiate an action at step 1216. For example, the action may beinitiated if there have been more than five unscheduled tasks in thepast month. Alternatively, the action may be initiated if the schedulefor the next month includes too many requests that were not scheduledwith tasks expected to be completed within the period of time. Thesystem may then return to step 1202 to receive a new request, or, thesystem may wait for a user interaction depending on the initiatedaction.

The initiated action may include issuance of a warning message. Thewarning may be displayed, for instance, as part of the serviceoptimization suite architecture shown in FIG. 5. The warning may includedata concerning how many requests were not scheduled with tasks expectedto be completed within the period of time. Alternatively, the action mayinclude automatically changing a scheduling constraint. For example, themethod may result in a constraint on work hours to be changedautomatically, such that field professionals work more hours each day inorder to accommodate a surge in requests for services.

F. Scheduling Location-Based and Location-Agnostic Tasks

Sometimes, services performed by field professionals require the fieldprofessional to physically visit a site to complete a task such asreplacing equipment. These types of tasks may be called location-based.Other times, a field professional task may be completed remotely,without the field professional visiting a site in person, such asremotely establishing an internet connection. These tasks may be calledlocation-agnostic. Furthermore, in some situations, a field professionalmay lose valuable time traveling between sites, for instance, duringhigh volume traffic times. Rather than this time being lost, the fieldprofessional could perform a remote task until the condition clears,maximizing productivity. The following disclosure describes methods andsystems that enables users to assign location-based tasks andlocation-agnostic tasks to a field professional. The system includes amemory, a network interface, and a processor connectable to the networkinterface. The system may therefore schedule tasks that arelocation-agnostic and tasks that are location-based in such a way so asto optimize field professional time. For instance, the system mayschedule a location-agnostic task chronologically between twolocation-based tasks, using predicted traffic delays, to reduce wastedtime. In some embodiments, the system may be implemented as taskscheduling unit 150.

FIG. 13 is a flowchart of an example process 1300 for a schedulingmethod for field professionals, consistent with the present disclosure.In some embodiments, server 152 may implement process 1300. For example,processing device 202 may receive data from I/O system 210 or networkinterface 206, and then execute instructions or program codes stored inmemory interface 204 or database 154, in which the instructions orprogram codes implement algorithms of process 1300. The algorithms ofprocess 1300 may be implemented as one or more of analysis module 441,forecasting module 442, planning module 443, or scheduling module 444.Process 1300 includes the following steps or operations.

At step 1302, a set of first requests for on-site assistance from afirst set of users is received. The set of requests may be one or morerequests, and may be received directly from users, for example, via anonline request, telephone call, and the like. Alternatively, therequests may be entered by a customer service unit 120 on behalf of auser, or the requests may be entered directly by a manager, director, orfield professional upon seeing a need for on-site assistance.

At step 1304, a second set of requests from a second set of users isreceived. The second set of users may be the same as or different fromthe first set of users. The second set of requests may be a singlerequest or many requests, and may be received before, simultaneously, orafter the first set of requests. The second set of requests may be forremote assistance, rather than on-site assistance.

Answering each of the set of first requests for on-site assistance mayrequire one or more field professional to travel to a locationassociated with a user from the first set of users. That is,location-specific tasks may include tasks that require one or more fieldprofessional to travel to a location associated with a user. These tasksmay only be completed with a visit to the user's location, and includetasks such as installing equipment, repairing equipment, connectingequipment, and the like. On the other hand, answering each of the set ofsecond requests for remote assistance may require the one or more fieldprofessional to connect via a communication network with a user from thesecond set of users. In other words, location-agnostic tasks may requirea field professional to connect via a communication network with a useror resource and may include services that may be accomplished virtually,such as setting parameters digitally, debugging internet connectivity,researching problems, troubleshooting, providing guidance over the phoneor email to operators or users, ordering parts, or speaking with otherfield service professionals for guidance. Location-agnostic tasks mayoptionally be completed at the site of the user, but they also may becompleted at any location so long as the field professional can connectvia a communication network with a user or, if necessary, a resource.

At step 1306, a plurality of location-based tasks associated with theset of first requests is assigned to one or more field professional.Thus, one or more field professional is assigned responsibility fortasks that address the set of first requests. Field professionals may benotified of the assignments in person or remotely, for example, via thefield professional communication device 180A.

At step 1308, the system receives real-time information includingcurrent location information of the one or more field professional. Thereal-time information may include information of if a task has beencompleted yet, or the location of the field professional.

At step 1310, it is determined, based on the real-time information,whether the one or more field professional can complete alocation-agnostic task associated with a second request after completinga first location-based task and before starting a second location-basedtask. Real-time information may include locations of tasks, trafficconditions, unexpected delays, or changes in task status, for example, atask being completed early or a task being unable to be completed,resulting in the field professional being unobligated earlier thanexpected. Additionally, expected task duration information may beconsidered.

Finally, after making the determination at step 1310, thelocation-agnostic task may be assigned to the one or more fieldprofessional at step 1312. The assignment may be recorded in a database154 of the task scheduling unit 150. Furthermore, the assignment may becommunicated to the field professional automatically, via the fieldprofessional communication device 180A, or by a manager who receives anotification from the system and approves the assignment beforenotifying the field professional.

Further illustration of the steps of process 1300 may be understood byreference to FIG. 14. At the beginning of a day, one or more fieldprofessional may be provided a planned field professional schedule 1410.The schedule shown includes driving times between location-specifictasks 1 and 2, tasks 1 and 2, and a location agnostic task 1. As the dayproceeds, the one or more field professional completes the scheduledactivities of driving and location-specific task 1. However, as shown inthe observed traffic 1420, shortly before 11:00, traffic on the routethat the one or more field professional would travel tolocation-specific task 2 becomes unusually heavy, perhaps due to a caraccident or roadway construction. If the one or more field professionalcontinued on the previously-planned sequence of tasks, namely, startingto drive at approximately 11:10 and then completing location-specifictask 2, the one or more field professional would not be able to starttask 2 until 13:00 due to traffic, as shown in resulting fieldprofessional schedule 1430. As a result, the field professional's dutyday may end before being able to accomplish location-agnostic task 1. Ifsuch a situation arose, process 1300 may be used to revise the scheduleof the field professional. In this case, after having completed steps1302, 1304, and 1306, at step 1308, real-time information may bereceived about the location of the field professional, as well asreal-time information about traffic conditions. At step 1310, based onthe real-time information of the traffic delay shown in the observedtraffic 1420 of FIG. 14, it may be determined that location-agnostictask 1 should be completed in the time that the field professional wouldbe stuck in traffic. The field professional's schedule may be revised,reassigning the field professional to complete location-agnostic task 1before starting location-specific task 2, as shown in revised filedprofessional schedule 1440. In this example, the field professional isable to accomplish three tasks during a shift due to process 1300,whereas, without process 1300, the one or more field professional wouldhave been able to complete only two tasks during the shift, withsignificant time spent being unproductive in traffic.

The determination of whether the one or more field professional cancomplete a location-agnostic task after completing a firstlocation-based task and before starting a second location-based task maybe based on field-location information. The field-location informationmay include information about the status of a site, such as weatherconditions, or status of the one or more field professional, such asprior task completion time or field professional location, that couldaffect the field professional's ability to perform a later task. Thefield-location information may be received from a wireless communicationdevice associated with the one or more field professional, such as thefield professional communication device 180A, and may be derived byusing a GPS signal or cell site location information, for instance. Thefield-location information may also be derived from other sensors orsources, both public, such as on the internet, and private, such asmonitoring devices owned by the user or field professional company. Insuch a manner, the field-location information may be provided andreceived automatically, without intervention of the field professional.Alternatively, the field-location information may be derived with theintervention of the field professional, for example, by phone calls,text message, or other communications placed by the field professional.

Information about traffic conditions associated with a field-locationfor one or more field professional may also be used to determine whetherthe one or more field professional can complete a location-agnostic taskafter completing a first location-based task and before starting asecond location-based task. For example, if traffic is unusually heavy,a field professional will have time to accomplish a location-agnostictask while waiting for traffic to clear. Alternatively, if traffic islight, the field professional should proceed to the nextlocation-specific task. Information about traffic conditions may bederived from publicly available data, including traffic trackingwebsites or government websites that show construction or emergencyclosures. Alternatively, information about traffic conditions may bederived from field professionals themselves. For example, if many fieldprofessionals are dispatched, and one or more encounters traffic, adelay may occur in that field professional's arrival at a task anddetermine traffic conditions. This information may be used determinewhether the field professional can complete a location-agnostic task.

Information about environmental conditions associated with afield-location for one or more field professional may be used todetermine whether the one or more field professional can complete alocation-agnostic task after completing a first location-based task andbefore starting a second location-based task. For example, somelocation-specific tasks may require working outdoors, and could beimpaired by high winds or thunderstorms, such as working on electricallines. The system may therefore obtain weather data from publiclyprovided sources or via reports from individual field professionals. Ifa severe thunderstorm is affecting the location of a location-specifictask, a field professional may not be able to start the task. In such acase, the system may determine that the field professional can completea location-agnostic task before starting a second location-based task.Environmental conditions may also be used to determine travel times, forinstance, if snowstorms will cause delays in arriving at a location.

One or more field professional may be scheduled to perform an additionallocation-based task after completing a first location-based task andbefore starting a second location-based task. Additionally, the one ormore field professional may be assigned a location-agnostic task insteadof the additional location-based task based on the real-timeinformation. For instance, a field professional may have a firstlocation-based task of installing a new cable television system atAddress 1 at 9:00, and a second location-based task of servicing a cablesystem at Address 2 at 13:00. The field professional may have anadditional location-based task of installing a new modem at Address 3 at10:30. The field professional may be assigned to complete alocation-agnostic task of remotely configuring a virtual private networkfor a client at 10:30, rather than completing the additionallocation-based task of installing a new modem, due to heavy traffic. Assuch, the inability of the one or more field professional to reach alocation associated with the additional location-based task at ascheduled time may be determined from real-time information. In theexample case above, the system may determine the inability of the fieldprofessional to reach Address 3 by 10:30 due to real-time trafficconditions between Address 1 and Address 3. Alternatively, if the firstlocation-based task of installing new cable television at Address 1requires more time than expected, the system may determine fromreal-time information about the delay that the field professional isunable to reach Address 3 by 10:30, and instead assign alocation-agnostic task to the field professional instead of theadditional location-based task.

A notice of cancellation of the additional location-based task may beused to estimate a free time window in a daily schedule of one or morefield professional. Based on the estimated free time window, it may bedetermined whether one or more field professional can complete thelocation-agnostic task after completing the first location-based taskand before starting the second location-based task. For example,continuing the above example, if the user that requested the additionallocation-based task at Address 3 cancels the 10:30 appointment, thefield professional may now have an unexpected free window in hisschedule. Rather than this time going unused, it may be determined,based on the estimated free window, whether the field professional cancomplete a location-agnostic task after completing the firstlocation-based task and before starting the second location-based task.The determination may be completed at any time. A notice of cancellationmay originate in a user, for example, if the user is not able to be atthe facility during the scheduled time, or the notice of cancellationmay originate from an employee, such as a manager or another fieldprofessional.

To aid in the determination, there may be an indication of an urgencylevel of the location-agnostic task associated with the second request.Based on the urgency level of the location-agnostic task, the additionallocation-based task may be reassigned to one or more second fieldprofessional and the location-agnostic task may be assigned to the oneor more field professional. The urgency notifications may have multiplelevels, such as low, medium and high, and may be based on a variety offactors, including user importance, paying higher fees for higherpriority service, and the like. The threshold at which the systemreassigns tasks may be independent of other considerations, such that,for example, high urgency tasks always are reassigned, or may take intoaccount other considerations, such as other delays that may beintroduced by altering the planned schedule.

Furthermore, information identifying the one or more field professionalas more suitable to provide the location-agnostic task than one or moresecond field professional may be obtained, and, based on thisinformation, the additional location-based task may be reassigned to theone or more second field professional and the location-agnostic task maybe assigned to the one or more field professional. The obtainedinformation may be obtained from system memory. Alternatively, theinformation may be derived from a user, such as a user requesting aparticular field professional who had previously serviced the facility.Also, information such as skills data, past experience, and ranking maybe used in identifying one or more field professional as more suitableto provide the location-agnostic task than the one or more second fieldprofessional.

For example, as shown in FIG. 15A, there may be two field professionals,field professional 1510 and second field professional 1520. Both may bequalified to install modems, but only field professional 1510 isqualified to establish virtual private networks remotely. If a hospitalemergency room's virtual private network fails, a high urgencynotification may indicate a necessary location-agnostic task ofrepairing the network. Subsequently, as shown in FIG. 15B, theadditional location-based task of a modem installation may be reassignedfrom field professional 1510 to second field professional 1520. Fieldprofessional 1510 may then be assigned the location-agnostic task ofremotely repairing the emergency room's virtual private network.Alternatively, field professional 1510 may have past experience with thehospital's network or superior past rankings by customers. Anycombination of these and other factors could be used to determine thatfield professional 1510 is more suitable to provide thelocation-agnostic task.

In another embodiment, one or more field professional may be instructedto initiate a location-agnostic task before driving to a locationassociated with a second location-based task. The instruction may beprovided by a variety of means, including automatically to the fieldprofessional communication device 180A, or posted to a publicly viewablecalendar. Alternatively, the instruction may cause a dispatch person topersonally notify a field professional via a phone call, radio call,email, or text message. Notifying the field professional before drivingto the location associated with the second location-based task reduceslost time and maximizes field professional utilization. Alternatively,the instruction may be provided to one or more field professional afterdriving at least part of the way to a location associated with thesecond location-based task. For instance, if an accident causes trafficto back up after a field professional departs for the secondlocation-based task, the system may notify the field professional tostop driving and complete a location-agnostic task while waiting fortraffic to clear. After completing the location-agnostic task, the fieldprofessional may be instructed to perform more location-agnostic tasksif the traffic still caused delays. Alternatively, the fieldprofessional may resume driving to the second location-based task uponcompletion of the location-agnostic task with or without furthernotification.

In another embodiment, historical traffic data may be used to determinea daily schedule of the one or more field professional. The dailyschedule may include at least one or a plurality of location-agnostictasks and a plurality of location-based tasks. Thus, in addition tolocation-agnostic tasks being scheduled on an ad hoc basis, they mayalso be scheduled in advance. For instance, if the historical trafficdata indicates that highways near the city are always congested between16:00 and 18:00, a daily schedule of a field professional may includelocation-agnostic tasks between 16:00 and 18:00 so that the fieldprofessional may be productive despite traffic delays. Historicaltraffic data may, for example, be derived from public sources, or fromhistorical trends as recorded for other field professionals. If thereare multiple times in a day when traffic is heavy, a fieldprofessional's schedule may include a plurality of location-agnostictasks. These may all be for a single user, or for a single type ofservice, or for many users, or many services.

In some embodiments, a second request may be received after one or morefield professional has started the first location-based task. That is, aschedule may be set prior to the start of the workday, but the schedulemay also change throughout the day in response to other factors such astraffic, environment, schedule conflicts, field professionalavailability, and the like.

Assigning a location-agnostic task to one or more field professional mayinclude sending a link to a remote assistance session to a mobile deviceassociated with the field professional. The mobile device may be thefield professional communication device 180A, or may be another device.The remote assistance session may be, for example, a remote desktopaccess tool, a virtual private network, or access to an administratorwebsite. The link may enable the field professional to complete thelocation agnostic task. Alternatively, assigning a location-agnostictask to one or more field professional may include transferring a callto a mobile device associated with the one or more field professional.The video call may connect a field professional with a user, withanother field professional, or with any other employee. The mobiledevice may be the field professional communication device 180A, or maybe another device. The video call may enable a field professional toprovide remote assistance or obtain further information and guidancerelated to the location-agnostic task.

G. Appointment Booking

Sometimes, services performed by field professionals are booked inadvance of the service. Booking in advance allows predictability forusers, managers, and field professionals. But coordinating many bookingrequests from many customers across an entire company's fieldprofessionals may be difficult. Furthermore, large companies with manyfield professionals and customers may have very complex schedules,making booking a single appointment that meets user and company needsvery time consuming. Additionally, user experience is degraded, andmanager time is lost when waiting on a system to book new appointments.The following disclosure describes automated methods and systems thatenable fast booking of appointments for scheduling tasks to fieldprofessionals. The system includes a memory, a network interface, and aprocessor connectable to the network interface. The system may thereforeprovide booking responses for requests to book a new appointment using amulti-route model. The multi-route model may be configured to determinebooking responses in different ways. For instance, a first method mayprovide fast response time, while a second method may provide highresponse accuracy. In this manner, a user or manager may be provided aquick booking response, improving user experience and reducing delays.In some embodiments, the disclosed methods may be implemented by taskscheduling unit 150.

FIG. 16 is a flowchart of an example process 1600 for a schedulingmethod for field professionals, consistent with the present disclosure.In some embodiments, server 152 may implement process 1600. For example,processing device 202 may receive data from I/O system 210 or networkinterface 206, and then execute instructions or program code stored inmemory interface 204 or database 154, in which the instructions orprogram code implement algorithms of process 1600. The algorithms ofprocess 1600 may be implemented as one or more of analysis module 441,forecasting module 442, planning module 443, or scheduling module 444.Process 1600 includes the following steps or operations.

At step 1602, a multi-route model for appointment booking fordetermining booking responses in different ways is stored. The model maybe stored in memory interface 206 or in a non-transitorycomputer-readable storage medium. The model may include, for example, amachine learning model, an algorithm of checking actual assignmentschedules to find schedule availability, and the like. The model mayrely on external data, for example, data received from the networkinterface 206 or database 154 that show field professional availability,typical appointment durations, preferred appointment times, and otherscheduling constraints. The multi-route model may include a plurality ofmodels to determine appointment availability.

At step 1604, a request to book a new appointment for a service isreceived. This request may be entered directly by a user, for example,on a company website. Alternatively, the request may be entered by amember of the customer service unit 120, or by a manager. Theappointment may be for an on-site, location-based visit by a fieldprofessional, such as, for example, performing veterinary procedures ona farm, or installing internet equipment at a house. The appointment mayalso be for performance of remote, location-agnostic services, such asconfiguring an internet connection, that may be performed at anylocation.

At step 1606, a first booking response for the request is output,wherein the first booking response is determined using the multi-routemodel. In one embodiment, the first booking response may be based onstatistical measures and does not necessarily provide accurate results.The first booking response may be provided immediately, by a companywebsite or a member of the customer service unit 120, or may be furtheranalyzed or processed before being provided. The first booking responsemay be one of a plurality of results provided by one of the models ofthe multi-route model.

At step 1608, the first booking response is verified based on a secondbooking response determined using the multi-route model. That is, themulti-route model may provide a plurality of results. The results may bethe same, or they may be different. Furthermore, each of the models inthe multi-route model may each produce a plurality of results for outputand verification. Thus, in step 1608, the response provided by one modelof the multi-route model is verified by another response provided byanother model of the multi-route model. Verification may occur bycomparing the first booking response to the second booking response. If,for instance, the second booking response shows that the first bookingresponse cannot be the basis of an appointment, perhaps due to aconflict in the schedule, step 1608 may identify that the first bookingresponse is invalid.

Further illustration of the steps of process 1600 may be understood withreference to the steps of process 1700 in FIG. 17A and FIG. 17B. Process1700 begins by receiving a request to book a new appointment for aservice at step 1702. After the request is received, a multi-route modelis executed. For example, at step 1704, a predictive machine learningalgorithm may be executed to determine a first booking response. Thepredictive machine learning algorithm may be implemented through anymachine learning technique. In some embodiments, the first schedulingmodel may use previous proposed times to determine the first proposedtime. For example, if previous cable installations occurred at 2:00 onTuesdays and internet installations occurred at 1:00 on Wednesdays, thefirst scheduling model may use this information when determining a firstbooking response for a new request for cable installation. Thus, at step1706, the predictive machine learning algorithm may determine a firstbooking response corresponding to the initial request for anappointment.

Subsequently, the first booking response is checked at step 1708 toensure that the booking response complies with user-related timeconstraints before outputting the first booking response. In otherwords, if the user identifies a period of unavailability when requestingan appointment, the first booking response is compared to theunavailable times. For example, a user may request, at step 1702, anappointment for installation of new solar panels. Furthermore, if theuser works or travels every Monday and Tuesday, the user may indicatethat Mondays and Tuesdays are unavailable. If the first booking responseis determined for Monday or Tuesday, the booking is rejected, andanother first booking response is determined. If the first bookingresponse complies with the user-related time restraints (or if there areno time constraints) the first booking response may be outputted at step1710. The output may be promptly displayed to a user or customer serviceagent, or it may be output for further processing before being displayedto a user.

In addition to submitting time constraints, a user may also submit auser-related time preference. The first and second booking responses maybe determined based on the user-related time preference. A timepreference may be, for example, a desire to have service completedbefore the 15th of the month. The user may submit time constraints andtime preferences, or time constraints only, or time preferences only, orno time constraints or time preferences at all. Furthermore, the usermay submit any number of time constraints or time preferences. Timeconstraints or time preferences may comprise any unit of timemeasurement, such as, for example, Mondays only, or before 10:00 AM, orduring the last week of a month, or during December.

Returning to step 1702, after a request for an appointment is received,a second model of the multi-route model is also initiated. The secondmodel may be initiated at the same time as, before, or after the firstmodel. As shown in step 1712, the second model may include checking anactual assignment schedule of a plurality of field professionals todetermine the second booking response. For instance, the second modelmay step through each workday and appointment time sequentially until anopen appointment time is determined. If there are many different fieldprofessionals, the schedule for the entire field professional work forcemay be very complicated and take a significant amount of time todetermine a second booking response that meets the user's servicerequirement. For instance, the first model of the multi-route model maybe more than twenty times faster the second model of the multi-routemodel, such that the first model takes one second and the second modeltakes twenty seconds or more. In some embodiments, the first model maybe 5 times, 10 times, 50 times, 100 times or more faster than the secondmodel. At step 1714, the second booking response is determined. Thesecond model may require enough time that the second booking responsemay be determined after the first booking response is outputted. In oneembodiment, the input for the first model may include a representationof the current state of the tasks Gantt and previous appointments offersdetermined by the second model.

At step 1716, the first booking response is verified based on the secondbooking response. Because the second booking response is determined by adifferent and perhaps more thorough process, the second booking responsemay provide an appointment that meets more of the necessary criteria ofthe initial request than the first booking response. Thus, the first andsecond booking responses may include different proposed times forproviding the service. For example, the first booking response may befor an appointment at 3:00 on a Thursday. However, the second model mayhave stepped through each day in the week and found that every fieldprofessional is unavailable on Thursday. As a result, the second bookingresponse may have been determined for an appointment at 3:00 on Friday.Thus, the first booking response for 3:00 on Thursday cannot be verifiedat step 1716. The criteria for verification may, for instance, be thatthe first and second booking responses are on the same day, within twohours, or on subsequent days.

At step 1730 of FIG. 17B, the first and second booking responses arecompared. In some situations, step 1730 may be No, as the first andsecond booking responses may provide the same result. The process mayterminate at this point. However, if the first and second bookingresponses differ, multiple options may be available. For instance,process 1700 may proceed to initiate an action to improve themulti-route model at step 1732. For example, the system may provide thesecond booking response, which may include a second proposed time, tothe predictive machine learning algorithm. In this way, the secondbooking response may be an additional training input to retrain thepredictive machine learning algorithm, thereby updating the predictivemachine learning algorithm with the second booking response.Furthermore, the predictive machine learning algorithm may be retrainedeven if the first and second responses are identical, so as to reinforcea correct result in the algorithm. Alternatively, a scheduled assignmentof at least one field professional may be changed when the first bookingresponse is different than the second booking response at step 1734. Inthis way, the first booking response may be retained, providing greaterconsistency to users such that the first booking response is retaineddespite initially being invalid. In some embodiments, both step 1732 andstep 1734 may be performed, such that both the multi-route model isimproved and a schedule assignment is changed.

In some embodiments, process 1800 shown in FIG. 18 may be used toschedule field professionals to on-site technical services. At step1802, a request for an on-site technical service associated with alocation is received. At step 1804, a first scheduling model and asecond scheduling model are used to determine proposed times forproviding the on-site technical service, wherein a first proposed timedetermined using the first scheduling model is determined faster than asecond proposed time determined using the second scheduling mode. Thefirst scheduling model may also be used to determine a first alternativeproposed time and the second scheduling model may also be used todetermine a second alternative proposed time. The first and secondalternative proposed times may be determined synchronously orasynchronously with the first and second proposed times. At step 1806,the first proposed time is provided before the second proposed time hasbeen determined. The first proposed time may be provided directly to theuser, or by an intermediary, such as a customer service representative.At step 1808, after the first proposed time is provided, a discrepancyassessment is performed between the first proposed time and the secondproposed time. This discrepancy assessment may return as a result theamount of time between the first and second proposed times. At step1810, based on results of the discrepancy assessment, an action isinitiated to improve scheduling of field professionals to on-sitetechnical services.

Further illustration of the steps of process 1800 may be understood byreference to the steps of process 1900 in FIG. 19A and FIG. 19B. At step1902, a first proposed time is provided to a user. This may be doneimmediately once a proposed time is determined, or after a delay. Theproposed time may also be provided to a user by any means ofcommunication, including mail, email, text, automated phone call, orpersonal phone call from a customer service representative. The user maybe given an opportunity to accept or reject the first proposed time. Ifthe user accepts the first proposed time at step 1904, the discrepancybetween the first proposed time and the second proposed time is comparedto a threshold at step 1906. If the discrepancy is higher than athreshold, with step 1906 being Yes, an existing assignment of a fieldprofessional may be attempted to be changed to meet the first proposedtime at step 1908. If the discrepancy is lower than a threshold, withstep 1906 being No, no further action may be necessary. For example, auser may accept a first proposed time for lawn service of 1:30 onWednesday. The second proposed time, which may be completed after theuser accepts the first proposed time, may reveal that 1:30 on Wednesdayis not actually possible by analyzing existing scheduled of fieldprofessionals. If the second proposed time is at 2:00 on Wednesday, andthe threshold is a four hour difference, the first proposed time thatwas accepted by the user may be maintained as an appointment, or thesecond proposed time that was not offered to the user may be set as anappointment, and the process stopped. If, however, the second proposedtime is for 3:00 on Thursday, step 1906 would be Yes, because thediscrepancy is greater than the example threshold of four hours. Anattempt would be made to reschedule an existing assignment of one ormore field professional to meet the first proposed time at step 1908.

If the attempt at step 1908 is successful, step 1910 would be Yes. Inthis case, the process stops. However, if the attempt were unsuccessful,for instance, if all field professionals were already obliged for theentire week, step 1910 would be No. In this case, the user may becontacted at step 1912 to propose a new time for providing the on-sitetechnical service at the location. The contact may occur after anyamount of delay, including, for instance, before a user has left abooking website or ended a call with customer service.

Returning to step 1904, if the user does not accept the first proposedtime, step 1904 would be No. As shown in FIG. 19b , it may next bedetermined if the second proposed time is different than the firstproposed time. In this step, the two proposed times may be different ifthey do not overlap at all, or, in alternative embodiments, they may bedifferent if they do not overlap fully. For example, an appointment from2:00 to 3:00 on Thursday may be considered to be different from, or thesame as, an appointment from 2:30 to 3:30 on Thursday. The amount ofdifference required for step 1920 to be Yes may therefore vary accordingto the needs of users, managers, and field professionals. If step 1920is Yes, the second proposed time may be offered to the user as analternative proposed time. If step 1920 is no, new proposed times may bedetermined at step 1924. For example, if the first proposed time is10:30 on Tuesday, and the second proposed time is 10:30 on Tuesday, andthe user refuses this appointment, new proposed times may be determined.If, however, the second proposed time were 12:00 on Tuesday, this secondproposed time may be offered as an alternative proposed time to the userat step 1922.

In alternate embodiments, a first alternative proposed time may bedetermined using the first scheduling model, in addition to the firstproposed time. Furthermore, a second alternative proposed time may bedetermined using the second scheduling model. If a user refuses thefirst proposed time, and the refusal is received before the secondalternative proposed time was determined, the first alternative proposedtime may be offered to the user. Alternatively, if the refusal isreceived after the second alternative proposed time was determined, thesecond alternative proposed time may be offered to the user. Forexample, the first scheduling model may identify the first proposed timeand the first alternative proposed time after a few milliseconds andmaybe even seconds before the second scheduling model. For instance, thefirst proposed time may be 8:00 on Monday and the first alternativeproposed time may be 9:00 on Tuesday. If the user rejects the 8:00Monday appointment before the second scheduling model is complete, the9:00 on Tuesday appointment may be offered. On the other hand, if thesecond scheduling model determines a second alternative proposed time of3:00 on Monday before the refusal is received, the 3:00 on Mondayappointment may be offered. In this way, the user is given the benefitof quick, responsive appointment scheduling, while also being providedmore robust results if the user is slow to respond and the results areavailable.

H. Offering Times for Service

When scheduling tasks to field professionals, users ordinarily desirethe earliest possible appointment time. Field professional companies mayalso desire to schedule appointments as early as possible in order toprovide services responsive to user needs. However, simply providing theearliest possible appointment may ignore other factors that areimportant to field professionals, such as added cost necessary toschedule the first available appointment. Furthermore, users may preferlower cost appointments and services over having the first availableappointment for every requested service. The following disclosuredescribes automated methods and systems that enable offering a laterappointment time when the cost of an earlier appointment time is toohigh. Customer may be incentivized to accept an alternative that is morecost effective for the field professional scheduler. For example, if afirst possible appointment time is associated with a cost that is muchhigher than a second possible appointment time, the system may offer theuser the second possible appointment time. Alternatively, the system maydetermine that neither of the appointment times are cost effective, andindicate to the user that there are no available appointment times. Thesystem includes a memory, a network interface, and a processorconnectable to the network interface. The system may therefore providean appointment that optimizes cost and wait times according to user andcompany needs. In some embodiments, the system may be implemented astask scheduling unit 150.

FIG. 20 is a flowchart of an example process 2000 for a schedulingmethod for field professionals, consistent with the present disclosure.In some embodiments, server 152 may implement process 2000. For example,processing device 202 may receive data from I/O system 210 or networkinterface 206, and then execute instructions or program code stored inmemory interface 204 or database 154, in which the instructions orprogram code implement algorithms of process 2000. The algorithms ofprocess 2000 may be implemented as one or more of analysis module 441,forecasting module 442, planning module 443, or scheduling module 444.Process 2000 includes the following steps.

At step 2002, a request to book a new appointment for a service expectedto be completed within a time period is received. The request may bereceived directly from a user, for example, via a website.Alternatively, the request may be entered by a member of the customerservice unit 120, or by a manager. The request may be for an on-site,location-based service by a field professional, such as, for example,performing veterinary procedures on a farm, or installing internetequipment at a house. The request may also be for performance of remote,location-agnostic services, such as configuring an internet connection,that may be performed at any location. The request may containinformation about when the service should be performed. This couldinclude user availability, such as after 5:00 on Tuesdays, or userurgency, such as within 24 hours. Alternatively, a company may specify arequired time period for different types of services, such as requiringthat all requests for vaccination services should be completed withinone week of request.

At step 2004, a first possible time slot and a subsequent secondpossible time slot for the new appointment within the time period areidentified. The time slots may be identified by any method. For example,each time slot in the time period may be examined sequentially to see ifan appointment could occur in each time slot. The first possible timeslot and the subsequent second possible time slot time within the timeperiod for the new appointment may be identified based on predicted useravailability data. Predicted user availability data may be derived from,for instance, social media, work hours, and historical appointment timepreferences provided by the user. A time slot that is possible becauseno field professionals are scheduled during the time may nonetheless notbe identified if the user is predicted to be unavailable during thetime.

At step 2006, a first scheduling cost associated with the first possibletime slot and a second scheduling cost associated with the secondpossible time slot are calculated. Different factors may be consideredwhen calculating the cost, because travel may require travel expenses,including for example tolls, gasoline, air or rail fares, per diem,lodging, and wages. A scheduling cost may be associated with a total ofdriving durations of a set of field professionals. Furthermore, ascheduling cost of possible time slots may be based on details ofpreviously scheduled tasks to a set of field professionals. For example,a cost may be the hourly wage of the field professionals multiplied bythe driving duration to the location of the requested service, or theprice of gasoline. Driving duration may include information aboutanticipated traffic, or the distance between the site of an immediatelypreceding appointment and the requested appointment location. Forinstance, a first possible time slot may immediately follow anappointment at a location 100 miles away from the requested appointmentlocation, while a second possible time slot may follow an appointment ata location only 5 miles away from the requested appointment location. Inthis example, the second possible time slot would be associated with alower cost, both because the set of field professionals would spend lesstime driving, and because the transportation cost of traveling 100 milesis more than the transportation cost of traveling 5 miles. In otherwords, driving duration may include both time and distance.

The cost may also be associated with a total number of tasks that can beassigned to a set of field professionals in a predefined period of time.In other words, some time slots may allow a set of field professionalsto be assigned to more tasks than other time slots. For example, a usermay request refrigerator repair service, expected to take one hour tocomplete. A first possible time slot may be between an appointmentending at 9:00 and an appointment beginning at 10:00, and a secondpossible time slot may be between an appointment ending at 10:00 and anappointment starting at 11:30. The second time slot may result in 30minutes of lost productivity and one fewer task for the shift, becausethere may be no tasks that a field professional can complete in lessthan 45 minutes. The cost may then be calculated based on the lostrevenue from performing one fewer task in a shift and the cost of wagespaid during unproductive employment time.

The cost may also be associated with a total number of fieldprofessionals working in a predefined period of time. In this manner,the number of field professionals working each day may better matchdaily needs. For example, the scheduler may minimize or reduce thenumber of professionals working each day. Furthermore, the cost may bebased on a daily schedule of each of a plurality of field professionals.This may enable greater optimization of scheduling all the fieldprofessionals as a whole. For instance, a first possible time slot mayoccur on a day when three field professionals are scheduled to work.However, the requested service may require a special skill set or be ina location that is far from the other appointments already scheduled forthe three field professionals. A fourth field professional may then beneeded to perform a service at the first possible time slot. The addedcost of assigning the appointment to the fourth field professional,thereby making the fourth field professional work, may therefore bebased in overtime pay, or the obligation of the company to pay the fieldprofessional a full day wage despite only performing a single task atthe first possible time slot. Thus, cost may reflect a managementpreference to minimize the number of field professionals working eachday.

The cost may also be associated with a total of the resources beingutilized in a period of time. For instance, a set of field professionalnurses may have access to a single inhalator. While a time slot may bepossible because one of the nurses is not scheduled during the time, theinhalator may be assigned to a different appointment during the time.Assigning an appointment at the time slot may therefore require rentalof a second inhalator. The cost may therefore be based in the rental orpurchase cost of additional equipment needed to perform a specific taskfor an appointment during the time slot.

Returning to FIG. 20, at step 2008, selection of the second possibletime slot is enabled when it is determined that both the firstscheduling cost and the second scheduling cost are below a schedulingcost threshold. Furthermore, enabling selection of the second possibletime slot may include outputting information reflecting the secondpossible time slot. For example, if the cost of both the first andsecond possible time slots are acceptable to the company, both may beoffered to a user so that the user has multiple options for appointmenttimes. If the second possible time slot has a cost above a schedulingcost threshold, only the first possible time slot may be output.Information reflecting the possible time slots may be output directly tothe user or indirectly to the user via a member of the customer serviceunit 120.

Any combination of total driving duration, total number of tasks, totalnumber of field professionals, and total resources being utilized may beused in determining a scheduling cost. Furthermore, scheduling costs maybe computed the same or differently for each of the identified timeslots.

Further, at step 2010, a no-available-time-slot notification is outputwhen it is determined that both the first scheduling cost and the secondscheduling cost are above the scheduling cost threshold. That is, if allavailable time slots within a time period are too expensive, the usermay receive a notification that there are no available time slots orappointments within the time period. The notification may includeoffering a time slot at a time after the time period, or a later timeslot within the time period, that may be below the scheduling costthreshold. The notification may be provided directly to a user, or to amember of the customer service unit 120.

FIG. 21 is a flowchart of an example process 2100 for a schedulingmethod for field professionals for on-site services in cases when ascheduling cost reflects driving duration. At step 2102, a user requestfor an on-site service associated with a location is received. That is,one or more field professionals may need to travel to the location toperform the service.

At step 2104, a first possible time slot for providing the on-siteservice at the location is identified, wherein the first possible timeslot is associated with a first field professional. At step 2106, afirst driving duration that would be added to a schedule of the firstfield professional if the first field professional is assigned toprovide the on-site service at the location is estimated based onpreviously scheduled tasks of the first field professional and trafficconditions. In other words, the driving duration may be determined basedon how far a field professional must drive to reach the location from aprevious location. The previous location may be the field professional'sresidence, or a dispatch center, or a location of preceding appointment.The traffic conditions may be predicted, for example, based on knowledgethat traffic driving into a city at 8:00 is known to add a thirty-minutedelay, or that a particular roadway is planned to undergo constructionthat will increase traffic delays. Additionally, the traffic conditionsmay also be real-time, based on live traffic updates on the internet orfrom field professionals, and may help scheduling of same-day or shortnotice appointments.

At step 2108, a second possible time slot for a second fieldprofessional to provide the on-site service at the location isidentified, wherein the second possible time slot is associated with asecond field professional. At step 2110, a second driving duration thatwould be added to a schedule of the second field professional if thesecond field professional is assigned to provide the on-site service atthe location is estimated based on previously scheduled tasks of thesecond field professional and traffic conditions. The second drivingduration may be estimated in the same manner as the first drivingduration.

Identification of the first and second possible time slots may becompleted in any manner. A schedule showing all field professionalstogether may be analyzed to identify the first possible time slot amongall field professionals. Alternatively, a first possible time slot maybe identified for a particular field professional, and a second possibletime slot, later than the first possible time slot, may be identifiedfor a different field professional. For example, field professional Amay have an available time slot of 10:00 on Wednesday, and fieldprofessional B may have available time slots of 9:00 on Tuesday and 9:00on Friday. The first possible time slot among all field professionals is9:00 on Tuesday, and the second possible time slot among all fieldprofessionals is 10:00 on Wednesday. However, field professional A maybe preferred, and so the first possible time slot may be identified as10:00 on Wednesday with field professional A, and the second possibletime slot may be identified as 9:00 on Friday with field professional B.

At step 2112, the user is provided a proposed time associated with thesecond possible time slot different from (e.g., later than) later thanthe first possible time slot when the second driving duration is lessthan the first driving duration. That is, although the first possibletime slot may be earlier, a later, second time slot may be preferredbecause the second time slot required less time lost while driving. Thismay occur if the distance the second field professional must travel froma preceding appointment to the location of the user request is shorterthan the distance the first field professional must travel from apreceding appointment. Alternatively, although a first distance may beshorter than a second distance, the first distance may require drivingon a route that requires more time due to speed limits and predicted orobserved traffic.

At step 2114, a no-available-time-slot notification is output if boththe first driving duration and the second driving duration are greaterthan a threshold. That is, a company may determine that drivingdurations greater than one hour result in too much lost productivity,and therefore implement a threshold that appointments are not availablefor time slots that would require more than one hour of drive time.

Further illustration of the steps of process 2100 may be understood withreference to the steps of process 2200 in FIG. 22. Process 2200 beginsat step 2202 by estimating first and second driving durations, forinstance, as in steps 2106 and 2110 in FIG. 21. At step 2204, the seconddriving duration is compared to the first driving duration. If the firstdriving duration is less than the second driving duration, step 2204 isNo, and a proposed time associated with the first possible time slot maybe provided to the user. If the second driving duration is less than thefirst driving duration, step 2204 is Yes, and other steps may occur.

For instance, at step 2206, the time difference between the seconddriving duration and the first driving duration is compared to athreshold. If the difference is smaller than a threshold, step 2206 isYes, and a proposed time associated with the first possible time slot isprovided to the user. If the difference is larger than the threshold,step 2206 is No, and step 2208 may occur. For example, if secondpossible time slot would save only a small amount of driving durationtime, such as only five minutes, the first possible time slot may bepreferred despite it requiring a longer driving duration. In someembodiments, the threshold may be dependent on the difference betweenthe first and second possible time slots. For example, if the firstpossible time slot is on Monday and the second possible time slot is onTuesday, the threshold may be set to five minutes, but if the secondpossible time slot is on Friday, the threshold may be set to two hours.In this way, the inconvenience of a delay between the first and secondtime slots may be balanced against the benefit of a shorter drivingduration.

At step 2208, the process 2200 predicts if an additional service wouldbe requested in proximity to the location. If an additional service ispredicted to be requested in proximity to the location, step 2208 isYes, and a time associated with the first possible time slot is providedto the user. The prediction may be done by any means, such as bycomparison to historical patterns of requests for service or weatherforecasts. Additionally, the proximity may reflect a threshold distance,such as ten miles, or a driving duration, such as twenty minutes. Inthis manner, a schedule may be constructed that anticipates user needsand reduces total driving duration for multiple appointments, even ifdriving duration for a single appointment, taken in isolation, isgreater than it could be for second possible time slot.

At step 2210, process 2200 confirms if the second field professional hasskills for completing the on-site service before providing the user theproposed time associated with the second possible time slot. The skillsmay be determined by reference to a database containing skillinformation of each field professional, or by directly asking a fieldprofessional in reference to a particular request for service.

At step 2212, process 2200 confirms if the second field professional hasreplacement parts for completing the on-site service before providingthe user the proposed time associated with the second possible timeslot. At step 2214, process 2200 confirms that the second fieldprofessional has at least one tool required for completing the on-siteservice before providing the user the proposed time associated with thesecond possible time slot.

The replacement parts and at least one tool required for completing theon-site service may be determined by reference to a standard list ofparts and tools needed for the type of service requested by a user.Alternatively, the replacement parts and at least one tool may bedetermined by communicating with a field professional to inform of therequested service and relying on the field professional to determinewhat replacement parts and tools are needed. A field professional may beconsidered to have replacement parts if the replacement parts are, forinstance, in a vehicle with the field professional, or easily accessedby a field professional, for example at a warehouse within apredetermined distance of the on-site service or accessed by a detouralong the route to the location requiring a driving time beneath athreshold. Information concerning the location of replacement parts andtools may be derived from wireless tracking tools, inventory logs, orcommunication with field professionals or warehouse employees.

If each of steps 2210, 2212, and 2214 are Yes, the process 2200 mayproceed to provide a proposed time associated with the second possibletime slot at step 2216. The proposed time slot may be provided directlyto the user, or to a customer service representative to provide to theuser. If the user refuses the proposed time associated with the secondpossible time slot at step 2218, step 2218 is Yes, and the process 2200may then provide the user a proposed time associated with the firstpossible time slot. If the user does not refuse the proposed time, step2218 is No, and the process stops. If any of steps 2210, 2212, and 2214are No, the process 2200 may proceed to step 2220 and provide the user aproposed time associated with the first possible time slot.

Any combination of steps 2204, 2206, 2208, 2210, 2212, 2214, 2216, and2218 may be utilized in process 2200. These steps may be performed inany order, and any of the steps may be omitted.

I. Scheduling Tasks Based on User Profile

When scheduling tasks to field professionals, a company that providesfield services may have to keep schedules of each of the fieldprofessionals. When a user requests an on-site service, the schedulermay need to find an available time slot in the schedule of the fieldprofessionals to accommodate the new request for service. However, atime slot that is available for a field professional may not beavailable for a user. Identifying time slots that are possible for fieldprofessionals as well as possible or even convenient for users increasescustomer satisfaction.

The following disclosure describes automated methods and systems thatenable identifying when a time slot is suitable for the requesting useras well as the field professionals. For example, if a field professionalhas multiple times slots available, but some of those times areunavailable for a user, the system may offer the user one of the timeslots that are available to both the field professional and the user.The system includes a memory, a network interface, and a processorconnectable to the network interface. In some embodiments, the systemmay be implemented as task scheduling unit 150.

FIG. 23 is a flowchart of an example process 2300 for a schedulingmethod for field professionals, consistent with the present disclosure.In some embodiments, server 152 may implement process 2300. For example,processing device 202 may receive data from I/O system 210 or networkinterface 206, and then execute instructions or program code stored inmemory interface 204 or database 154, in which the instructions orprogram code implement algorithms of process 2300. The algorithms ofprocess 2300 may be implemented as one or more of analysis module 441,forecasting module 442, planning module 443, or scheduling module 444.Process 2300 includes the following steps.

At step 2302, a user request for an on-site service is received. Therequest may be received in a variety of ways, including directly from auser, for example, via a website. Alternatively, the request may beentered by a member of the customer service unit 120, or by a manager.The request may be for an on-site, location-based service by a fieldprofessional, such as, for example, performing veterinary procedures ona farm, or installing internet equipment at a house. The request may beaccompanied by a time period, provided by the user along with therequest or by a company as a standard of service for a type of on-siteservice.

At step 2304, a set of possible time slots for providing the on-siteservice is identified based on a schedule of a set of fieldprofessionals. The time slot may be identified by any method. Forexample, time slots in a time period may be examined sequentially to seeif an appointment could occur in each time slot.

At step 2306, information indicating an availability of the user toaccept the on-site service is retrieved. This information may take onmany different forms. For instance, the information may be from at leastone online source. The online source may be, for example, social mediaor a publicly viewable calendar. The information may be direct, such asa user publicly posting their work hours, or the information may bederived from user patterns, such as analysis of a user's social mediaposting history showing that no posts were made between 8:00 and 9:00 onweekdays, indicating that the user is likely commuting to work duringthat time. In accessing this information, user permission to crawl theat least one online source may be requested and, if the user approves,the user permission may be accepted as well. In some embodiments, therequest may only occur if a search of publicly available informationyields insufficient information.

The information may also be retrieved from a profile associated with theuser. This profile may be stored in the system's database. The profilemay also be an online profile, created by a user when establishing arelationship with the field professional company. The data in theprofile may be supplied directly by the user, or the data may be createdby the company based on past answers of the user to proposed times foron-site services. For example, if a user always declines time slotsbefore 10:00, a profile may be created for the user that records thatappointments before 10:00 should not be offered. Alternatively, theprofile may record the user's directly inputted choice that appointmentsafter 12:00 should not be offered. In this manner, the user's profilemay or may not be directly viewable or editable by the user.

At step 2308 a subset of possible time slots for providing the on-siteservice is determined based on the retrieved information indicative ofan availability of the user. The subset may be determined by comparingthe information from step 2306 to the set of time slots from step 2304.The set of possible time slots for providing the on-site service mayinclude times in which field professionals can arrive to a locationassociated with the user, and the subset of possible time slots forproviding the on-site service may include times in which fieldprofessionals can arrive to the location and there is a likelihood thatthe user will be present at the location. Mutually exclusive times maybe ignored, with remaining times forming the sub-set. For example, theset of possible time slots of when a field professional is availablefrom step 2304 may include 8:00 on Monday, Tuesday, and Wednesday. Theinformation from step 2306 may show that the user is only available at8:00 on Tuesday, Wednesday, and Thursday. Thus, the intersection of thetwo sets, namely, 8:00 on Tuesday and Wednesday, form the subset ofpossible time slots. The subset of possible time slots may be less than25% of the set of possible time slots, either by cumulative time, suchas a subset of 1.5 hours of time slots in comparison to a set of 8 hoursof time slots, or by total number, such as one time slot, regardless ofduration, in a subset and five time slots in a set.

Determining the subset of possible time slots for providing the on-siteservice may be based on profiles of other users. Behavior analytics mayreveal that other users with similar profiles have a pattern ofappointment preferences. For example, if a requesting user's profileshares a corporate address with many other users who prefer appointmentsafter 4:00 on weekdays, the subset of appointments may be determinedbased on appointments after 4:00 on weekdays. This could happen even ifthe requesting user has not indicated that he prefers appointments after4:00 on weekdays. Similar analysis of profiles of other users, such asinformation about demographic data, spending with the company, or typesof services requests, may be used to determine the subset as well.

Furthermore, determining the subset of possible time slots for providingthe on-site service may be based on information associated with aweather forecast. For example, if the on-site service requires workoutside, time slots should not be offered for periods when bad weatheris expected. A weather forecast may be near term, such as rain beingforecast for Tuesday, or long term, such as snow being expected at aservice location between November and March that prevents installationof a large piece of equipment.

Additionally, determining the subset of possible time slots forproviding the on-site service may be based on information associatedwith the request. For example, if a user requests the service at anaddress known to be for the user's work location, either byself-identification by the user or by looking up the address associatedwith an incoming call, the subset of times may be determined to beduring work hours. Alternatively, if the user requests service using ahome phone number rather than a work phone number, the subset of timesmay be determined to be outside of work hours.

At step 2310, a time is proposed for providing the on-site service basedon a time slot selected from the subset of possible time slots. Theproposed time may be delivered directly to the user or indirectly to theuser via a member of the customer service unit 120. Alternatively, thetime may not be delivered to the user at all, but instead may be savedfor further processing. In some embodiments, at least one time slotassociated with a field professional may be selected based on a locationassociated with the user and locations of tasks previously assigned tothe field professional. That is, if there are many time slots in thesub-set, and some of them are preceded by appointments far from thelocation associated with the request and others are preceded byappointments close to the location associated with the request, the timeslots preceded by appointments closest to the requested location may bepreferred. Alternatively, the distances may be in relation toappointments immediately following the time slot. In this way, a companymay prefer to suggest a time slot when there is already a fieldprofessional scheduled in proximity to the user's location. After thetime is proposed, a task may be scheduled for a field professional afterthe user accepts the proposed time.

FIG. 24 is a flowchart of an example process 2400 for a schedulingmethod for field professionals for on-site services in cases when a usercannot keep an appointment. At step 2402, a time is proposed to a userand, at step 2404, the user accepts the proposed time and theappointment may be scheduled.

At step 2406, online activities of the user are monitored to determine alikelihood that the user will not be available to accept the on-siteservice at the proposed time. For example, the user may make a publicpost on social media about traveling to China on Monday but has anappointment scheduled for Tuesday, or, after granting access to privateaccounts, the system may find hotel reservations for the same day as anappointment to install equipment. At step 2408, the process may use thisinformation to determine a likelihood that the user will not beavailable to accept the on-site service at the proposed time. If it islikely that the user will be available still despite the onlineactivities, step 2408 is No and the process proceeds to step 2410.

At step 2410, the process retrieves updated information indicative ofthe availability of the user to accept the on-site service. This updatedinformation may be information the user provides directly to the fieldprofessional company, for instance, by email, website, or phone call.The updated information may also contain updated user availability for adifferent appointment time.

At step 2412, after receiving any updated information or determiningthat it is likely the user will not be available with step 2408 beingYes, the system determines if a previously scheduled appointment of theuser needs to be rescheduled. This determination may be based on theretrieved updated information, or on the likelihood determination fromstep 2408, or a combination of both. The determination may includecomparing the new unavailability with the previously scheduledappointment. If the user will be unavailable for a small portion of theappointment, or if the appointment does not need the user to be presentfor the service to be performed, the process may determine that theappointment does not need to be rescheduled, and step 2412 is No. Inthis case, the process returns to monitoring online activities of theuser at step 2406.

However, if step 2412 is Yes, for instance because the user must be hometo let a field professional into the house or to supervise the fieldprofessional's work, then the proposed time for providing the on-siteservice may be updated from the previously scheduled appointment at step2414. In process 2400, any combination of steps 2406, 2408, and 2410 maybe omitted. If step 2406 is omitted and a previously scheduledappointment does not need to be rescheduled such that step 2412 is No,the process may return to retrieve updated availability information ormay simply stop.

FIG. 25 is a flowchart of an example process 2500 for a schedulingmethod for field professionals, consistent with the present disclosure.At step 2502, a request for a service is received from a user. Therequest may be received directly from a user, for example, via awebsite. Alternatively, the request may be entered by a member of thecustomer service unit 120, or by a manager. The request may be for anon-site, location-based service by a field professional, or the requestmay be for a remote, location-agnostic service, such as, for example,setting up a virtual private network.

At step 2504, a first possible time slot for providing the service isidentified. The first possible time slot may be associated with a firstfield professional. The first possible time slot may be determined byexamining the schedule of a particular field professional, or the firstpossible time slot may be determined by examining all schedules of allfield professionals. In other words, the time slot may be the first timeslot because it is associated with a first field professional, or thetime slot may be the first time slot because it is the first availableslot overall, regardless of which field professional it is associatedwith. At step 2506, a second possible time slot different from the firstpossible time slot may be identified for a second field professional toprovide the service. The second possible time slot may be associatedwith a second field professional. The second possible time slot may beidentified in the same manner as the first possible time slot. Thesecond possible time slot may be at least one day later than the firstpossible time slot. Alternatively, the second possible time slot may bein an afternoon and the first possible time slot may be in a morning ofa day.

At step 2508, information indicative of an availability of the user toaccept the service is retrieved. The information may be from at leastone online source. The online source may be social media, or a publiclyviewable calendar. The information may be direct or derived fromanalysis. The information may be retrieved from a profile associatedwith the user, as well, which may be for instance private data obtainedfrom the user's accounts with the user's permission, public data fromsocial media or governmental records, historical appointmentinformation, demographic data, or profiles of similar users.

At step 2510, a proposed time associated with the second possible timeslot may be provided when the retrieved information suggests that theuser will not be available for the service during the first time slot.For example, a likelihood may be determined that the user will beunavailable during the first possible time slot based on historicalappointment information. If a user has never accepted an appointmentoffered after 12:00, the user may be likely to be unavailable for a newappointment during a first time slot of 12:30. Additionally, profiles ofother users with similar demographic data, such as age, gender, orincome, may be used to determine a likelihood that the user will beunavailable during the first possible time slot. For instance, if theuser is a 30 year old male with an income greater than some threshold,and other 30 year old males with similar incomes are found to declineappointments during working hours, the user may be likely to beunavailable during a first possible time slot that falls during workinghours. The user may be provided the proposed time associated with thesecond possible time slot based on the likelihood that the user will beunavailable during the first possible time slot. The likelihood may beabove some threshold set by the company. The determination of whether toprovide a proposed time associated with the second possible time slotmay also be based on if the service is location-based, such that theuser must be present for the service to occur, or location-agnostic,such that the user does not need to be present for the service to occur.

J. Scheduling Tasks from Customer Location

When a field professional provides a service to a user, sometimes thetask assigned to the field professional cannot be completed in onevisit. This may occur for a variety of reasons. For example, the fieldprofessional may not have the proper tools, supplies, or training onhand to complete a task. Other times, a user may request the incorrectservice. For example, a user with a faulty internet connection mayassume that a field professional needs to fix a modem, but when thefield professional inspects the problem, the field professional maydiscover that an underground line is broken, requiring an entirelydifferent service to correct the issue. In other cases, additionalproblems may arise during the service. For example, a field professionalservicing an air conditioner may plan on replacing refrigerant in thesystem, but, while performing this service, the field professional maydiscover a dangerous ground fault in the air conditioner system thatcould start a fire. In some situations, inclement weather may preventthe service being performed. These examples illustrate that a fieldprofessional may realize, in the course of performing a task in thefield, that an additional appointment will be needed to fully addressthe user's needs.

The following disclosure describes methods and systems that enablescheduling of a repeat, or follow-up, appointment with a user. Thesystem may receive data from a field professional located in the fieldat a customer's location. The received data may indicate that anadditional visit at the customer is needed. The system may take intoconsideration other requirements and provides the field professionalwith at least one time slot for offering the customer. The systemincludes a memory, a network interface, and a processor connectable tothe network interface. In some embodiments, the system may beimplemented as task scheduling unit 150.

FIG. 26 is a flowchart of an example process 2600 for a schedulingmethod for repeat visits by field professionals, consistent with thepresent disclosure. In some embodiments, server 152 may implementprocess 2600. For example, processing device 202 may receive data fromI/O system 210 or network interface 206, and then execute instructionsor program code stored in memory interface 204 or database 154, in whichthe instructions or program code implement algorithms of process 2600.The algorithms of process 2600 may be implemented as one or more ofanalysis module 441, forecasting module 442, planning module 443, orscheduling module 444. Process 2600 includes the following steps.

At step 2602, a user request for an on-site service is received. Therequest may be received directly from a user, for example, via awebsite. Alternatively, the request may be entered by a member of thecustomer service unit 120, or by a manager. The request may be for anon-site, location-based service by a field professional, such as, forexample, performing veterinary procedures on a farm, or installinginternet equipment at a house. The request may be accompanied by a timeperiod within which the service should be performed, provided by theuser along with the request or by a company as a standard of service fora type of on-site service.

At step 2604, information is transmitted to a field professional. Theinformation may reflect an assignment to provide the on-site servicerequested by the user at step 2602. The information may be transmittedusing the network interface. The information may include details aboutthe assignment, such as time, expected duration, required tools andequipment, and location of the service. The information may also includedirectional instructions to the location associated with the on-siteservice. The directional instructions may be driving instructions. Insome embodiments the directional instructions may also includeinstructions on navigating a site. For example, if a field professionalis needed to install a sensor at a large oil refinery plant, thedirectional instructions may include a driving route to the entrance ofthe facility, as well as directions inside the facility to theinstallation site, such as to install the equipment on tank 3 behind thesecond berm on the north side of the plant. The directions may beprovided by dispatchers or managers at the field professional company,by other field professionals, or by the user requesting the service.

At step 2606, an indication may be received that an additional visit isrequired to complete the on-site service. The indication may be receivedfrom the field professional or the user while the field professional isin the field at the user's location. The indication may be received byan automated system via a network interface 206, by a manager, a memberof the customer service unit 120, or another field professional. Theindication may be sent from a communication device associated with theuser, such as a smart phone app, a phone call to the customer serviceunit 120, or via a website. Alternatively, the indication may be sentfrom a communication device associated with the field professional, suchas field professional communication device 180A. The indication may alsoinclude a time estimation of work required in the additional visit. Thetime estimation may include the time required on site to perform theservice, as well as the travel time required. The indication may includean estimated travel duration derived from navigation software or fieldprofessional experience. The indication may be based on a fieldprofessional's estimate of the time required, or the indication may bebased on known times required for types of services. For example, afield professional may input a type of service needed, such as replacinga valve. An automated system may access a database containing timesaccording to tasks, find that, for instance, valve replacements requirean hour, and attach the time to the indication automatically. Theindication may also provide information about when the additional visitmay occur. For example, if a field professional is installing cabinetsand knows that glue must dry for three days before a next step may becompleted, the field professional may provide this information in theindication.

Furthermore, the indication may also include details of spare partsrequired in the additional visit, and task details of the additionalvisit may be updated to include the spare parts. Similarly, theindication may also include details of what tools are required in theadditional visit, and the task details of the additional visit may beupdated to include the required tools. The field professional may alsoindicate that spare parts or tools must be ordered. The indication mayalso include details of what field professional skills are needed tocomplete the on-site service of the additional visit. The indication mayinclude at least two of a time estimation of the work required in theadditional visit, details of spare parts required in the additionalvisit, details of tools required in the additional visit, and details ofskills of a field professional required in the additional visit.

At step 2608, a schedule of the field professional may be accessed toidentify at least one available time slot to schedule an additionalvisit in the future. The at least one available time slot may beidentified within a predefined time period. For example, the predefinedtime period may cause only time slots within four workdays to beconsidered. The predefined time period may be determined based on thenature of the task, such that some urgent requests may lead to quickerappointment times.

Furthermore, when identifying an available time slot, the timeestimation may be taken into account. For example, if the fieldprofessional or a system identifies that a farm veterinarian willrequire two hours to perform, free time slots in the fieldprofessional's schedule that are shorter than two hours may be ignored.Alternatively, identifying the available time slot may includereassigning a task previously assigned to the field professional toclear a time slot associated with the time estimation in a schedule ofthe field professional. For example, if a septic tank repair isestimated to require five hours and a septic tank repairman has anopening from 8:00 to 12:00, the septic tank repairman's appointment at12:00 may be reassigned to 1:00 so that the 8:00 to 1:00 time slot iscleared. The additional visit may take place during this time with thetime slot associated with the time estimation cleared. Alternatively,previously assigned task may be reassigned to a different fieldprofessional to clear the time slot in the original field professional'sschedule. In some embodiments, ff a schedule of the field professionalis full during a predefined time period, the tasks in the schedule ofthe field professional may be checked to see which tasks may bereassigned to a different field professional.

In some embodiments, the additional visit may be by a different fieldprofessional with a different skill set. For example, a cable televisioninstaller may know that an electrician is needed to completeinstallation of a cable box. In this case, the cable installer may sendan indication that an additional visit is required by a different fieldprofessional, and a future schedule of a different field professionalmay be accessed to identify a time slot.

If the task requires a field professional with a required skill set, aschedule of a field professional having the required skill set may beaccessed to identify an available time slot. In this way, a situationwherein a field professional arrives at a location but cannot completethe required work because he does not have the necessary skills may beavoided, increasing user convenience and satisfaction while alsoreducing costs from wasted field professional time and travel. Whenaccessing the schedule of a field professional having the required skillset, a next time where the field professional having the required skillset is scheduled to arrive an area proximate to the location may beidentified. The proximity may vary according to company and userrequirements. For field professional services that span an entirecountry, for instance, an area proximate to the location may be hundredsof miles away. For companies with smaller service areas, the areaproximate may be only a few miles. Alternatively, the area proximate tothe location may be measured as a traveling duration rather than adistance.

Furthermore, if spare parts or tools are required in the additionalvisit, identifying the available time slot may include confirming thatthe spare parts or tools required in the additional visit are available.For example, if a spare part or tool must be ordered from a manufactureror transferred from a warehouse, there may be a delay before a fieldprofessional is able to complete the additional visit. Thus,appointments that would occur before a shipping delay is over may beignored so that only time slots that occur after the required parts ortools become available are considered.

At step 2610, at least one proposed time for the additional visitassociated with the identified time slot is provided. The proposed timefor the additional visit associated with the identified time slot may beprovided to the user through a communication device associated with theuser while the field professional is at the user's location.Additionally, the proposed time for the additional visit associated withthe identified time slot may be provided to the field professionalthrough a communication device associated with the field professionalwhile the field professional is at the user's location. The proposedtime may be provided to the same person who provided the indication instep 2606. It may also be provided to the other person who did notprovide the indication in step 2606. Furthermore, the indication may beprovided to the same or different device type that provided theindication. The indication may also be provided to multiple devices.Furthermore, information reflecting an assignment associated with theadditional visit may be transmitted to the field professional while thefield professional is at the location. In this way, the user and fieldprofessional may have prompt confirmation that the additional visit willoccur so that the task may be completed. The information may include thedate and time for the additional visit.

Further illustration of the steps of process 2600 may be understood withreference to the steps of process 2700 in FIG. 27. Process 2700 mayoccur in conjunction with process 2600. Process 2700 begins at step 2702with receiving an indication, while the field professional is at alocation in the field where a service is being performed, that anadditional visit is required to complete the on-site service. At step2704, a plurality of available time slots is identified. The time slotsmay be for a single or a plurality of field professionals. The pluralityof available time slots may be identified by stepping through theentirety of a set time period. For example, every time slot that doesnot have an appointment may be identified for every field professionalin a one-week period. Alternatively, the plurality may include a setnumber of available time slots, regardless of the time range the timeslots define. For example, three time slots may be required for theplurality, even if sixth months of schedule must be analyzed beforefinding three available time slots. In some embodiments, the pluralitymay be set by processor time. For example, the plurality may include allavailable time slots found in five seconds of analysis, therebyproviding a user prompt service.

At step 2706, proposed times for the additional visit associated withthe identified plurality of available time slots are provided. Theproposed times may be provided to the field professional, the user, orboth. Additionally, the proposed times may be provided directly to thefield professional or user via a communication device, or the proposedtimes may be provided to a member of the customer service unit toprovide to the field professional or user.

At step 2708, the user selection indictive of a preferred time isreceived. Alternatively, the field professional may provide anindication of a preferred time as well. The selection may be received byproviding a list of the plurality of time slots, or a portion thereof,to the user, for instance by displaying the proposed time slots on asmart phone app or on a website. The user may select which of theproposed time slots he prefers. If a preferred time was selected, step2708 would by Yes, and the process 2700 stops. However, if the userindicates that none of the proposed times are preferred, step 2708 isNo, and process 2700 may proceed to step 2710.

At step 2710, information is retrieved indicative of an availability ofthe user. This information may be retrieved directly from the user byprompting the user for availability information. For example, the usermay indicate that time slots after 3:00 would be acceptable.Alternatively, at step 2710, information about the user may be retrievedfrom a profile that reflects the user's appointment history anddemographics.

At step 2712, a subset of possible time slots for the additional visitis determined, based on the retrieved information indicative of anavailability of the user. Mutually exclusive times may be ignored, withremaining times forming the subset. For example, if the plurality ofavailable time slots comprised 3:00 on Tuesday, 4:00 on Wednesday, and1:00 on Thursday, and the retrieved information showed that the user wasunavailable before 3:00 on weekdays, the subset of possible time slotsmay be 3:00 on Tuesday and 4:00 on Wednesday.

At step 2714, proposed times for the additional visit associated withthe determined subset of possible time slots are provided. The proposedtimes may be provided to the user or the field professional. Afterproviding the proposed times, user acceptance of one of the times may bereceived, and an appointment may be scheduled for that time.

In some embodiments, steps 2706 and 2708 may be omitted, such thatinformation indicative of an availability of a user is retrieved withoutfirst proposing times to the user. Alternatively, steps 2710, 2712, and2714 may be omitted, and any remaining proposed times from the pluralityof available time slots may be proposed to the user. Alternatively, thetime period may be expanded or more processing time allowed to find moreproposed times to be provided to the user until the user accepts a time.

K. Scheduling Tasks Using Customer Feedback

Field professionals often provide one of the main interactions between acompany and a customer. The relationship between the company and thecustomer is often shaped by the quality of the service provided by afield professional. Understanding a customer's perception of the qualityof service provided by the field professional can therefore be used toimprove the relationship between the customer and the company byimproving future customer satisfaction. For example, if a customer isvery pleased with a service provided by a field professional, a companymay decide to assign the same field professional to perform futureservices. Alternatively, if a customer is dissatisfied with a serviceprovided by a field professional, a company may decide to not assignthat same field professional to perform future services for thecustomer. Customer satisfaction may be based on quality of service,professionalism, or personal interactions, for example. By tailoringfield professional assignments to past customer satisfaction, a companymay maintain good customer satisfaction or improve poor customersatisfaction, thereby retaining and adding users.

The following disclosure describes methods and systems that enablescheduling of a field professional based on data including customersatisfaction associated with prior service. The system may receive datafrom a customer during or after a service is completed. Based on thatdata, the system may decide whether to assign the same fieldprofessional or a different field professional for future tasksassociated with the same customer. The system includes a memory, anetwork interface, and a processor connectable to the network interface.In some embodiments, the system may be implemented as task schedulingunit 150.

FIG. 28 is a flowchart of an example process 2800 for a schedulingmethod for repeat visits by field professionals consistent with thepresent disclosure. In some embodiments, server 152 may implementprocess 2800. For example, processing device 202 may receive data fromI/O system 210 or network interface 206, and then execute instructionsor program code stored in memory interface 204 or database 154, in whichthe instructions or program code implement algorithms of process 2800.The algorithms of process 2800 may be implemented as one or more ofanalysis module 441, forecasting module 442, planning module 443, orscheduling module 444. Process 2800 includes the following steps.

At step 2802, a customer request for at least one on-site serviceassociated with a location is received. The request may be for a firston-site service, for example, or one in a series of services. Therequest may be received directly from a customer via a website.Alternatively, the request may be entered by a member of the customerservice unit 120, or by a manager. The request may be for an on-site,location-based service by a field professional, such as, for example,conducting a medical evaluation prior to purchasing life insurance orinstalling a septic tank. The request may be accompanied by a timeperiod within which the service should be performed, provided by thecustomer along with the request or by a company as a standard of servicefor a type of on-site service.

At step 2804, a field professional is assigned to at least one task ofproviding the at least one on-site service at the location. Theassignment may be transmitted to the at least one field professionalusing the field professional communication device 180A, for example, byemail, text message, or phone call. The assignment may include detailsabout the assignment, such as time, expected duration, required toolsand equipment, and location of the service. The at least one fieldprofessional may be assigned randomly, or based on criteria such asskillset and availability.

At step 2806, data associated with the on-site service is obtainedfollowing completion of the at least one on-site service. The data isfurther illustrated by reference to FIG. 29, showing that the dataassociated with service may be based on five types of data sources,discussed below.

Data source 2902 shows that the data associated with the on-site servicemay be determined based on a sentiment analysis of a recording of aninteraction between a field professional and the user during the atleast one on-site service. For example, the field professionalcommunication device 180A may record a conversation between a customerand a field professional. The audio recording may be later analyzed toidentify key words indicating customer sentiment about the interactionbetween the field professional and customer during a visit.Alternatively, tone of voice may be analyzed to determine if a customeris showing negative emotions, such as anger or frustration, or positiveemotions, such as happiness, during conversations with the fieldprofessional. Alternatively, a phone call between a customer an anymember of the company, including a field professional or a customerservice representative, may be recorded and similarly analyzed. Therecording may be made during a visit, but analyzed at the same or adifferent time. In some embodiments, the information is digitally signedby the customer to ensure authenticity in later processing.

Data source 2904 shows that following completion of the at least oneon-site service, feedback may be received from the customer. The dataassociated with the at least one on-site service may be determined basedon the received feedback. The feedback may be solicited from thecustomer immediately after the service by the field professional, or maybe solicited by the company by an email, phone call, or text messageafter the service completes. Alternatively, the feedback may beunsolicited, and provided by the customer without prompting. Thefeedback may be, for example, a star rating, such as three out of fourstars, or a level of satisfaction, such as options for very satisfied,satisfied, not satisfied, and the like.

Data source 2906 shows that following completion of the at least oneon-site service, metadata information associated with the at least oneon-site service may be received. Metadata may be information or otherindications that are automatically sent without a field professional orcustomer explicitly deciding to send it. For example, if a fieldprofessional has a task to set up an internet connection, the time ofthe first login from the customer's address may be metadata informationshowing at least the task is in progress at the time. In the case of anelectrician, for example, the times at which electricity is turned offand turned on may be metadata information. Thus, metadata may includetime information, and may show that a field professional has arrived,started a task, completed a task, different phases of a task, or leftthe location. Metadata information may also location information showingwhere the field professional was at different times. Time and locationinformation may be compared to the appointment time and the expected jobduration to show the punctuality and efficiency of a field professional.In some embodiments, metadata information associated with the at leastone on-site service may be received from at least one communicationdevice associated with the at least one field professional. For example,the metadata information may include GPS readings of a cell phonecarried by a field professional, or cell site location information.Furthermore, the metadata information may also include information aboutmessages sent by the field professional, such as information showing anyaddresses that sent messages to or received messages from the fieldprofessional. Message address information may show how many times afield professional had to contact another person for assistance, or, insome cases, if a field professional was distracted from performing thetask due to sending and receiving messages.

Data source 2908 shows that following completion of the on-site service,data associated with the at least one on-site service may be determinedfrom posts that the user published in a social network. For example, acustomer may post information on a social networking website indicatingsatisfaction with the service provided, such as thanking the company forgood service. A customer may also post information showingdissatisfaction, such as posting a complaint. The customer's post may bediscovered by finding the customer on a social networking site by usingknown information about the customer, such as email address and name.Alternatively, a customer's post may be found by the customer directingthe message to the company, such as tagging a company's profile in apost about the quality of service. A user's post may also appear on awebsite that hosts reviews of businesses, and a company may link reviewsto recently performed service.

Data source 2910 shows after the on-site service was completed, dataabout the on-site service may be received from the field professional.The data may be submitted by the field professional communication device180A, or by a form filled out by the field professional, and may includeinformation such as any issues encountered during the service and thefield professional's estimation of the customer's satisfaction. It mayalso include details on what service was performed, for example,recording that the field professional administered a vaccine to all ofthe calves on a farm over three months old or details on anyinfrastructure that was installed, so that a future service may haverecords of past services.

Element 2912 shows that data from any combination of the sourcesillustrated as data sources 2902, 2904, 2906, 2908, and 2910 may be usedin determining data associated with service. Once data has beencollected, the data associated with the on-site service may be used todetermine a level of satisfaction 2914 from a work of the fieldprofessional. For example, algorithms may be used to determine the ratioof positive words to negative words used by the customer, or weight maybe given to customer satisfaction or reviews. Different data may havemore significance than others. For example, a social network postdirected to a company directly complaining of a service may have moreimpact on the determined level of satisfaction than metadata showingthat the field professional arrived at a site on time and completed theservice quickly.

Returning to FIG. 28, at step 2808, an additional customer request foran additional service associated with the same location is received. Forexample, the additional request may be for a second service, after afirst service. The task of providing the second service may be alocation-agnostic task associated with the first on-site service. Forexample, if an internet modem was installed during a first task, asecond task may require changing connection settings. The second taskmay be accomplished from any location by logging into a modem andchanging the settings, such that the task may be location-agnostic.Alternatively, the task of providing the second service may be alocation-based task independent of the first on-site service. Forexample, a first task may be installing an internet modem, and a secondtask may be installing a cable television connection, such that thesecond task is independent of the first on-site service and is performedat a specific location. The additional service may also belocation-based and dependent on the prior on-site service, such ascompleting an installation or correcting an error in earlier work. Therequest may be made by the same customer or someone with a relationshipwith the customer, such as a spouse.

After the request is received, information including data associatedwith the at least one on-site service is retrieved at step 2810. Theinformation may be saved in database 154, for instance. The informationmay also contain expected durations of different services and fieldprofessional availability and skillsets. At step 2812, a fieldprofessional is assigned to perform the additional service based on theretrieved information. For example, the same field professional thatperformed a first task may be assigned to provide a second service basedon the retrieved information.

Step 2812 may be further illustrated by reference to FIG. 30. FIG. 30shows process 3000 for assigning an additional service based onretrieved information. After data is retrieved at step 3002, the processcompares the difference in time between the previous service and thenext request for service. If a time difference between a first time whenthe first on-site service was provided and a second time when the secondrequest is received is below a predefined period of time, step 3004 ifYes, and the same field professional may be assigned to accomplish thetask. In other words, if step 3004 is Yes, the process may skip step3006. For example, if a mobile veterinarian administers medicine to asick cow on a farm and the customer the next day requests additionalmedical attention because the cow is not recovering, the sameveterinarian may be assigned to the task. By assigning the same fieldprofessional to subsequent tasks that are requested within a predefinedperiod of time, the field professional may provide better, quickerservice and the customer have greater satisfaction because there wouldbe continuity of care and familiarity with the user's issues. If,however, the difference is greater than a predefined period, such as amonth later, the process proceeds to step 3006, because there may be areduced benefit of familiarity due to the delay between a first andsecond service.

At step 3006, the level of satisfaction from the work of the fieldprofessional is compared to a threshold. The threshold may be anumerical calculation based on the data, or a qualitative determination.Alternatively, the determination may be made by a manager assessing thedata. The level of satisfaction may be customer-dependent, such thatonly the requesting customer's level of satisfaction from prior workwith the field professional is compared to the threshold. Alternatively,the threshold may be customer dependent, for instance, premium customersmay be sent field professionals with high satisfaction scores acrossmany customers. If the level of satisfaction from the work of the fieldprofessional is less than a threshold, step 3006 is No, and a new fieldprofessional may be assigned to the task at step 3008. In this way, acompany may avoid sending a field professional to the same customer whoalready was disappointed by the field professional's service. However,if a certain field professional or plurality of field professionalsprovided the at least one on-site service, and the level of satisfactionfrom the work of the certain field professional or plurality of fieldprofessionals is greater than a threshold, step 3006 is Yes, and thecertain field professional or plurality of field professionals may beassigned to perform the additional on-site service. In this way, usersmay continue having high levels of satisfaction by having the same fieldprofessional for each subsequent services.

At step 3010, the on-site service is analyzed to determine if itincluded a plurality of on-site services provided by a plurality offield professionals. If there were two or more, step 3010 is Yes, andthe process selects which of the plurality of field professionals toassign to perform the additional on-site service based on the dataassociated with the on-site service. The selected group may be a singlefield professional, or may be a subset of the plurality of fieldprofessionals that performed the at least one on-site service. Forexample, if three electricians worked together to install a hot tub at ahotel, the level of customer satisfaction of one electrician may behigher than the level of customer satisfaction of the other twoelectricians. If the hotel then requests service for the hot tub, thefirst electrician may be selected to perform the service because he hada higher level of customer satisfaction. Alternatively, if a plumber andan electrician installed a hot tub at a hotel, and a motor on the hottub pump failed, the electrician may be selected to perform the servicebecause the data shows that an electrician is needed to service a motor,not a plumber. Once a selection is made, the process then proceeds tostep 3014. Alternatively, if only a single field professional performedthe at least one on-site service, the process may proceed directly tostep 3014 without performing step 3012.

At step 3014, the process determines if the field professional orplurality is available to provide the service. This determination may bebased partly on a time period within which the service must or should beperformed, determined either by company standards or customer requestthat the service be provided within some amount of time. If the certainfield professional's schedule is full during a predefined time period, atask previously assigned to the certain field professional may bereassigned to enable assigning the certain field professional to theadditional on-site service at step 3016. Similarly, if a plurality offield professionals is selected at step 3012, the schedule of theplurality or a schedule of each individual in the plurality may beanalyzed and tasks reassigned so each individual of the plurality may beassigned the additional on-site service.

At step 3018, the field professional or the plurality of fieldprofessionals may be assigned to perform the additional service. Whileperforming process 3000, any of the steps may be omitted as desired by acompany. For example, a company may omit determining if the differencein time between the previous service and the next service is less than apredefined period of time because, for instance, the types of servicesoffered by the company do not benefit from having the same fieldprofessional perform subsequent tasks.

FIG. 31 shows a process 3100 of suggesting a field professional to auser. After selecting a field professional based on the data associatedwith the at least one on-site service at step 3102, step 3104 determinesif the additional service is of a different type than the on-siteservice already performed. If the additional service is of a differenttype than the at least one on-site service, step 3104 is Yes, and adifferent field professional is selected at step 3106. A suggestion of adifferent field professional for the additional service may then bepresented at step 3108. The different field professional may be selectedbased on a necessary skillset needed to perform the additional service.However, if the additional service is of the same type as the at leastone on-site service, step 3104 is No, and, at step 3108, the fieldprofessional selected in step 3102 based on the data associated with theat least one on-site service may be suggested for the additional on-siteservice. The field professional may be suggested to a manager orcustomer service representative at step 3108, or directly to the user.

For example, if data associated with a first service performed showsthat a certain field professional planted apple trees for a customer,and a customer requests a second service to plant more apple trees, theservices may be of the same type, and step 3104 is No. The same fieldprofessional therefore may be suggested to the customer based on dataassociated with the first service. However, if the customer requests asecond service to cut down other trees to provide more sunlight to theapple trees, the second service may be of a different type from thefirst service. In this case, step 3104 is Yes, and a different fieldprofessional may be suggested to the user. Different types of servicesmay be determined by a company based on the skillset needed to perform aservice, such that, for example, all tasks that can be completed by anelectrician are the same type.

After a field professional is suggested at step 3108, process 3100determines if the suggestion was accepted at step 3110. If thesuggestion was accepted, step 3110 is Yes, and the field professional isassigned to the task at step 3112. However, if the suggestion wasdeclined, step 3110 is No, and the system may return to step 3106 anddetermine a different field professional. This cycle may continue untila suggestion is accepted at step 3110. Once a suggestion is accepted,the corresponding field professional may be assigned to perform theservice at step 3112. In this manner, a customer may have the same fieldprofessional if the customer was satisfied with the field professional'swork, or may decline the same field professional if the customer wasunsatisfied with the first field professional's work. The customer mayalso choose between multiple field professionals until a fieldprofessional is satisfactory to the customer. Alternatively, a managermay also choose between multiple field professionals to choose theoptimal field professional to perform a task.

L. Systems and Methods for Fixing Schedule Using a Remote OptimizationEngine

Scheduling tasks for field professionals requires a system to predictvalues of numerous scheduling parameters. One example of thesescheduling parameters is the “task duration,” the time it takes for afield professional to complete a task at the client's location. Anotherparameter is the “travel duration,” the time it takes for a fieldprofessional to travel to the client's location. Allocating a timeperiod for a certain task significantly shorter than the actual taskduration (or the actual travel duration) may result in dispatchershaving to take immediate action to fix the schedule, postponing tasks,or requiring more field professionals to meet the demand. Theseimplications may attribute to poor customer service. On the other hand,allocating a time period for the certain task significantly longer thanthe actual task duration (or the actual travel duration) may result inunder-utilization of field resources, post revenue, or poor customerservice. The following discussion refers to task duration and travelduration; however, a person skilled in the art would recognize thatvalues of other scheduling parameters may be predicted and used by thedisclosed system.

FIG. 32 shows a bar graph illustrating actual task duration distributionof single task type. As shown, the task duration may vary significantly.Factors that may influence the task duration may include differentcharacteristics of the field professionals (e.g., skills, experience,etc.), the time of day, the weather, the location of the task, thecomments from the client at the time of scheduling, and more. When afixed value of 45 minutes is assigned by default to all tasks from thistask type, only about 30% of the tasks are within the margin of error often minutes of the default value, about 40% of the tasks takes between 1to 2.5 hours, and about 25% of the tasks takes less than 30 minutes.Therefore, taking a naive approach of assigning a predetermined valuefor the scheduling parameter task duration would result in anunoptimized schedule.

The present disclosure discloses a system (e.g., system 100) with aoptimization engine that takes into consideration different factors forpredicting the task duration and other scheduling parameters for aspecific task. Consistent with the present disclosure, the system mayconstantly or periodically receive information for calculating thescheduling parameters. In one example, the received information may beassociated with past task durations (e.g., last month when Bob wasassigned to this type of task it took him 70 minutes on average, butthis month his average is about 57 minutes). In another example, theinformation may include traffic data associated with travel durationpredictions (e.g., last week it was estimated to take 20 minutes onaverage to travel from point A to point B between 10:00 and 15:00; thisweek it is estimated to take 15 minutes to travel from point A to pointB between 10:00 and 15:00).

In some embodiments, the system may provide schedule optimizationservices to different service providers. An example configuration forthese embodiments may include a central server with an optimizationengine and a plurality of local servers, each with its own nativescheduling engine. The central server may be separate or remote from thelocal server. Namely, different servers may host the optimization engineand the native scheduling engines. In some cases, this separation isimportant because service providers (associated with the local servers)may not wish to share details on their clients with third party services(such as the schedule optimization service providing the centralserver). Because the optimization engine may have access to more updatedinformation regarding different scheduling parameters, the optimizationengine may provide more precise results than the native schedulingengines. However, the local servers cannot simply use the resources ofthe central server without sharing confidential or private information.The following disclosure describes a process by which local servers canbenefit from the optimization engine without sharing details on theircustomers. In other words, the present disclosure shows a technicalsolution that provides an improvement to the functioning of acomputerized system with optimization engine by communicating schedulingdata between the central server and one or more local servers.

FIG. 33 is a schematic illustration of a system 3300 for schedulingtasks to field professionals. System 3300 may include a central server3305 and a plurality of local servers 3330 (e.g., a local server 3330A,and a local server 3330B). Central server 3305 may include at least onememory (e.g. a memory device 3310), a communication interface (e.g., anetwork interface 3320), and at least one processor (e.g., a processor3315) connectable to the communication interface and the at least onememory. Similarly, each of local servers 3330 may include at least onememory (e.g. a memory device 3335A and memory device 3335B), acommunication interface (e.g., a network interface 3345A and a networkinterface 3345B), and at least one processor (e.g., a processor 3340Aand a processor 3340B). In the following discussion, the functionalityof the components of local server 3330A are described in detail. Localserver 3330B is assumed to have similar components with similarfunctionalities.

System 3300 may include one or more local servers 3330 for communicatingwith users and scheduling tasks to field professionals. The memorydevice of local server 3330A may be configured to store data associatedwith scheduled tasks. For example, memory device 3335A may be configuredto store task data 3336A, scheduling data 3337A, and client data 3338A.In one embodiment, task data 3336A may include information about tasksthat were scheduled during a defined period of time, such as dates,times, task type, task location, skills requirement per task, toolsrequirement per task, spare parts requirement per task, etc. The definedperiod of time may be more than a week, more than a month, more than ayear. Scheduling data 3337A may include a plurality of schedulingparameters associated with the native scheduling engine 3341A. Thescheduling parameters may include, for example, estimated tasks durationtimes for different task types, estimated travel duration times fordifferent rides at different times of the day, and more. Client data3338A may include details of the clients associated with the scheduledtasks, such as client profiles (e.g., name, age, gender, profile photos,work place), contact details (e.g., contact information, phone number,email address, home address), client history (e.g., details about lastservices provided, such as service feedbacks, complaints, or comments),and more. Consistent with the present disclosure, task data 3336A mayinclude general information that can be shared with central server 3305and client data 3338A may include private information about the clientsthat should not be shared with central server 3305.

The processor of local server 3330A may be configured to schedule tasksto field professionals 110 using a native scheduling engine 3341A. Thecommunication interface of local server 3330A may be configured tocommunicate with field professionals 110, users 130, and central server3305. Specifically, network interface 3345A may receive a set ofrequests for on-site assistance from users 130 and real-time informationfrom a set of field professionals. The term “a set of fieldprofessionals” in this disclosure refers to one or more fieldprofessionals. The communication interface of local server 3330A mayalso be configured to transmit task data 3336A and scheduling data 3337Ato central server 3305 and to avoid transmitting client data 3338A.

System 3300 illustrated in FIG. 33 also includes central server 3305 forupdating a scheduling engine that schedules tasks to fieldprofessionals. Central server 3305 may be configured to access dataassociated with a scheduling engine (e.g., a native scheduling engine3341A 3316 and/or a native scheduling engine 3341B). For the purpose ofthe following discussion, a distinction is made between the types ofmemory associated with central server 3305. Memory 3318 is the primarystorage of central server and it is a type of memory which temporarilystores data (also referred to as a volatile memory). The primary storagemay be directly associated with processor 3315. Examples of the primarystorage may include Random Access Memory (RAM), Dynamic Random-AccessMemory (DRAM), Synchronous Dynamic Random-Access Memory (SD RAM). Memory3318 may also be associated with a memory device that permanently storesa predefined set of instructions for internal operation of the centralserver 3305. Memory device 3310 is the secondary storage of centralserver 3305 and it is a type of memory which is non-volatile andpersistent in nature. It allows a user to store data that may beinstantly and easily retrieved, transported, and used by applicationsand service. Examples of the secondary storage may be a magnetic harddisk, an optical disk, or another form of storage for large amounts ofdata. Central server 3305 may be synchronized with a cloud storageservice.

In one embodiment, the secondary storage of central server 3305 (i.e.,memory device 3310) may store scheduling data 3311 and a predictionmodel 3312. In one embodiment, scheduling data 3311 may includeinformation associated with previously completed tasks scheduled by atleast one scheduling engine other than native scheduling engine 3341A.For example, scheduling data 3311 may include information associatedwith tasks scheduled by native scheduling engine 3341B. The informationmay include specific details about the scheduled tasks and/or statisticsabout the scheduled tasks. In another embodiment, scheduling data 3311may be associated with traffic predictions. For example, scheduling data3311 may include estimated travel durations, weather forecasts, detailsregarding public events that may cause atypical traffic conditions(e.g., parades, marathons, and demonstrations), and more. In anotherembodiment, scheduling data 3311 may be associated with task durationpredictions. In this embodiment, scheduling data 3311 may be associatedwith a task type, a time of day, a customer type, a task location,skills of field professionals, and more. Scheduling data 3311 mayinclude that collection of data be used for determining a predictionmodel 3312.

In addition, memory device 33310 of central server 3335 may beconfigured to store a prediction model (e.g., prediction model 3312).The term “prediction model” refers to a specific model associated withtask scheduling derived by applying a prediction method to a collectionof data. The prediction method may include a combination of methods fromthe fields of statistics, machine learning, artificial intelligence, anddata mining. Consistent with the present disclosure, central server 3305can train and update prediction model 3312 based on data received fromfield professionals 110, users 130, local servers 3330, and/or otherdata sources 3350. Consistent with the present disclosure, processor3315 may update prediction model 3312 based on data that periodicallyreceived from local server 3330A and/or local server 3330B. A differentprediction model may include a different version of prediction model,i.e., different values for the same scheduling parameters.

In some embodiments, the processor of central server 3305 may beconfigured to utilize an optimization engine 3316 and an in-memoryprocessing module 3317 for checking performances of native schedulingengine 3341A. As used herein, the term “optimization engine” refers tosoftware, firmware, hardware, or a combination thereof for generating atask assignment plan for a set of field professionals. In oneembodiment, the optimization engine may be associated with softwareinstructions and a prediction model that may be stored in the secondarystorage. When the software instructions are executed, at least some ofthe data stored in the secondary storage is loaded by processor 3315into the primary storage. Thereafter, processor 3315 may be configuredto execute the software instructions associated with the optimizationengine in the primary storage.

The term “in-memory processing module” refers to software, firmware,hardware, or a combination thereof for processing in a stateless mannerat least part of the data received from local server 3330A. In-memoryprocessing module 3317 enables directly loading the data received fromlocal server 3330A into the primary storage (e.g., memory 3318) withoutpassing into the secondary storage. Although in-memory processingrequires implementation of a large primary storage, it eliminates theneed for retrieving data from the secondary storage (e.g., memory device3310). Accordingly, the term “processing in a stateless manner” refersto a type of data processing that does not keep track of configurationsettings, transaction information, or any other historical informationabout the processed data. When processor 3315 processes data receivedfrom local server 3330A, at least some of the data is stateless (i.e.,it does not maintain state). Specificity, central server 3305 preventsat least part of the data received from local server 3330A frommaintaining state. In other words, central server 3305 prevents at leastpart of the data received from local server 3330A from being saved inthe secondary storage.

The communication interface of central server 3305 may be configured tocommunicate with one or more local servers 3330, field professionals110, users 130, and data source 3350. Data source 3350 may be associatedwith a volatile or non-volatile, magnetic, semiconductor, tape, optical,removable, non-removable, or other type of storage device or tangible ornon-transitory computer-readable medium. In one embodiment, data source3350 may provide traffic data, map data, and toll road information,which may be used for task scheduling. The traffic data may includehistorical traffic data and real-time traffic data regarding a certaingeographical region. In one embodiment, the traffic data may be used to,for example, calculate estimate travel durations and determine anoptimal route for a particular field professional. Real-time trafficdata may be received from a real-time traffic monitoring system, whichmay be integrated in or independent from data source 3350. The map datamay include map information used for navigation purposes, for example,for calculating potential routes and guiding professionals to locationsassociated with the tasks. The toll road information may include tollcharges regarding certain roads and any change or updates thereof. Tollroad information may be used to calculate optimal routes for the fieldprofessionals to locations associated with the tasks.

FIG. 34 is a message flow diagram showing example communications betweendifferent elements of a scheduling system in accordance with a process3400. In the following description, reference is made to certaincomponents of system 3300 for purposes of illustration. It will beappreciated, however, that other implementations are possible and thatother components may be utilized to implement methods disclosed herein.

Process 3400 starts when central server 3305 requests scheduling datafrom data source 3350 (message 3402). Thereafter, central server 3305may receive scheduling data from data source 3350 (message 3404). Thescheduling data may be used to update the optimization engine. Forexample, a certain road may be under maintenance and travel duration isexpected to be longer. Independently to actions performed by centralserver 3305, local server 3330A may receive requests for on-siteservices from a plurality of users 130. In one embodiment, each of therequests may require a field professional to travel to differentlocations associated with a corresponding user. Local server 3330A mayuse its native scheduling engine to generate task schedule. Thereafter,local server 3330A may send the scheduling data associated with itsnative scheduling engine and/or task data to central server 3305(message 3406 and message 3408).

Central server 3305 may process in a stateless manner the received taskdata using the optimization engine. In one embodiment, processor 3315may detect at least one task that local server 3330A, using its nativescheduling engine, had scheduled in an unoptimized manner. In oneexample, a task scheduled in an unoptimized manner may be a task inwhich the estimated task duration is determined to be longer (orshorter) than the task duration currently allocated in the schedule. Inanother example, a task scheduled in an unoptimized manner may be a taskin which the estimated travel duration to the task is determined to belonger (or shorter) than the travel duration currently allocated in theschedule. Thereafter, processor 3315 may identify a factor that causesthe native scheduling engine of local server 3330A to schedule tasks inthe unoptimized manner, provide to the local server 3330A informationsuch as the identified factor (message 3410). After processing in astateless manner, the task data from local server 3330A, processor 3315may update its prediction model (prediction model 3312). In oneembodiment, updating the prediction model may take into account theidentified factor that caused the native scheduling engine of localserver 3330A to schedule tasks in the unoptimized manner.

In some embodiments, local server 3330A may use the information receivedfrom central server 3305 to update its native scheduling engine. Localserver 3330A may also review the previously scheduled set of tasks toidentify at least one task scheduled in an unoptimized manner.Alternatively, central server 3305 may also transmit details of at leastone task determined to be scheduled in an unoptimized manner. Consistentwith the present disclosure, the scheduling system prefers not to makeschedule changes that require contacting clients that had alreadyscheduled a service and change their appointment times. Accordingly,local server 3330A may determine a likelihood that the task scheduled inan unoptimized manner will require dispatchers to take immediate actionfor fixing the schedule. And in some cases, local server 3330A may causea schedule change associated with the identified task. FIG. 35illustrates an example of the schedule change and FIG. 36 illustrates anexample of decision tree for changing the schedule.

FIG. 35 is a schematic illustration of two daily schedules 3500A, 3500Baccording to a disclosed embodiment. Each daily schedule shows the timesand durations of tasks assigned by local server 3330A to four fieldprofessionals (Arnold, Bruce, Chuck, and Donald) between 8:00 and 16:00of a workday. A person skilled in the art would recognize that an actualscheduling system can manage the daily schedules of more than 10 fieldprofessionals, more than 50 field professionals, and/or more than 100field professionals. The upper schedule 3500A shows details of tasksthat local server 3330A had assigned to each of the field professionalsusing the native scheduling engine. The lower schedule 3500B showsdetails of tasks that local server 3330A assigned to each of the fieldprofessionals using an updated version of native scheduling engine. Inthis disclosure, the term “updated version of native scheduling engine”may refer to different scheduling engines, different versions of a samescheduling engine, or a scheduling engine with different values ofscheduling parameters. Originally, as shown in the upper schedule 3500A,Arnold was assigned to tasks 3501, 3502, and 3503; Bruce was assigned totasks 3511, 3512, 3513, and 3514; Chuck was assigned to tasks 3521,3522, 3523, 3524, and 3525; and Donald was assigned to tasks 3531, 3532,3533, 3534, and 3535.

Local server 3330A may use the updated native scheduling engine on thepreviously scheduled set of tasks to identify one or more tasksscheduled in an unoptimized manner. For example, local server 3330A maydetermine that 1) in Arnold's schedule, task 3502 was originallyassigned with a longer task duration than a time it is estimated totake; 2) in Bruce's schedule, tasks 3513 and 3514 were originallyassigned with a shorter task duration than the times they are estimatedto take; 3) in Chuck's schedule, task 3524 was originally assigned witha shorter task duration than a time it is estimated to take; and 4) inDonald's schedule, task 3532 was originally assigned with a shorter taskduration than a time it is estimated to take. In view of the newestimations of the task durations (determined using the updated nativescheduling engine), local server 3330A may change the schedule toprevent a situation in which dispatchers have to take immediate actionto fix the schedule. Specifically, as shown in the lower schedule 3500B,local server 3330A had updated the estimated task durations, reassignedtask 3524 from Chuck to Arnold, reassigned task 3532 from Donald toBruce, and rescheduled task 3514 to a different day.

FIG. 36 is a flowchart of an example process 3600 used by a processingdevice of local server 3330A (e.g., processor 3340), according toembodiments of the present disclosure. Process 3600 begins when theprocessing device determines a likelihood that a task scheduled usingthe native scheduling engine will result in a failure to completeanother task (block 3602). Thereafter, the processing device maydetermine whether the likelihood is greater than a threshold (decisionblock 3604). If the likelihood is less than the threshold (i.e.,changing the schedule is not necessary but may improve utilization offield resources), the processing device may determine if changing theschedule would require changing task time (decision block 3606).Typically changing a task time would require contacting a client and maylead to negative costumer experience. When changing the schedule doesnot require changing the task time, the processing device is configuredto cause the schedule change associated with the task (block 3608). Forexample, this type of schedule change may include reassigning tasks todifferent field professionals and does not require changing the tasktime. When changing the schedule requires changing the task time, theprocessing device is configured to avoid causing the schedule changeassociated with the task (block 3610). If the likelihood that a taskpreviously scheduled will cause a failure to complete another task isgreater than the threshold, the processing device may use the updatednative scheduling engine to identify alterative task times (block 3612).The alterative task times may be offered to the client. Thereafter, theprocessing device is configured to cause the schedule change associatedwith the task (block 3614).

FIG. 37 depicts an example method 3700 in accordance with an embodimentfrom the perspective of a central server (e.g., central server 3305).Method 3700 may be used for updating a scheduling engine of a localserver (e.g., local server 3330B) that schedules tasks to fieldprofessionals. For purposes of illustration, in the followingdescription reference is made to certain components of system 3300. Itwill be appreciated, however, that other implementations are possibleand that other components may be utilized to implement the exemplarymethod. It will also be readily appreciated that the illustrated methodcan be altered to modify the order of steps, delete steps, or furtherinclude additional steps.

At step 3702, a processing device (e.g., processor 3315) may accessstored data (e.g., scheduling data 3311) associated with an optimizationengine (e.g., optimization engine 3316). At step 3704, the processingdevice may periodically receive from a remote server (e.g., local server3330B) a data associated with a native scheduling engine (e.g., nativescheduling engine 3341B) (e.g., task data 3336B and/or scheduling data3337B). In one embodiment, the processing device may receive from theremote server data associated with tasks that were scheduled during adefined period of time. The period of time associated with the scheduledtasks may be defined by the processing device, by the remote server, orby an operator of system 3300. In some examples, the processing devicemay periodically receive from the remote server data associated withtasks that were scheduled during a period of less than a month, a periodof less than two months, a period of less than three months, a period ofmore than two days, a period of more than ten days, and a period of morethan twenty days.

At step 3706, the processing device may process in a stateless mannerthe data periodically received from the remote server using optimizationengine to update a prediction model. Consistent with the presentdisclosure, processing the data associated with the scheduled tasks in astateless manner may be done by avoiding storing in memory device 3310the data associated with scheduled tasks. Alternatively, processing thedata associated with the scheduled tasks in a stateless manner may bedone by avoiding storing in memory device 3310 personal details includedin the data associated with scheduled tasks. In one embodiment, themethod may include detecting that the native scheduling engine scheduleda task in an unoptimized manner by determining that a field professionalassigned to the task is estimated to arrive at a location associatedwith the task before or after a time estimated by the native schedulingengine. For example, the native scheduling engine scheduled a first taskto start at 11:00 AM, but the optimization engine determines that afirst field professional assigned to the first task will not arrive tothe location associated with the first task before 11:25 AM. In anotherembodiment, detecting that the native scheduling engine scheduled a taskin an unoptimized manner may include determining that a fieldprofessional assigned to the task is estimated to complete the taskbefore or after a time estimated by the native scheduling engine. Forexample, the native scheduling engine reserved in the schedule 2.5 hoursfor completing a second task, but the optimization engine determinesthat a second field professional assigned to the second task willcomplete the second task in less than an hour and may be available foran additional task. In yet another embodiment, detecting that the nativescheduling engine scheduled a task in an unoptimized manner may includedetermining that a field professional assigned to the task does not havea skill set required to complete the task on time. In one example, athird field professional may be assigned to a third task of installing acertain product, but the optimization engine determines that the thirdfield professional did not complete the training for installing thatcertain product. In a further embodiment, detecting that the nativescheduling engine scheduled a task in an unoptimized manner may includedetermining that other field professionals may compete the task fasterthan the field professional currently assigned to the task. In oneexample, this type of task takes a fourth field professional 35 minutesmore than the average time of other field professionals, and it isbetter to assign the third field professional to other types of tasks.In some embodiments, the processing device may identify at least onefactor that causes the native scheduling engine to schedule tasks in theunoptimized manner. With reference to the three examples above, the atleast one factor that caused the native scheduling engine to scheduletasks in an unoptimized manner may include inaccurate estimations oftravel durations, inaccurate estimations of task durations, inaccurateskill requirements per task, and/or inaccurate statistics on fieldprofessionals. In one embodiment, the processing device may identify acombination of factors that causes the native scheduling engine toschedule tasks in the unoptimized manner.

At step 3708, the processing device may transmit information associatedwith the updated prediction model to the remote server for enablingimprovement of the native scheduling engine. Improving the nativescheduling engine may include updating the native scheduling enginebased on the identified at least one factor. Consistent with the presentdisclosure, the information transmitted to the remote server may beassociated with a plurality of scheduling parameters. For example, theinformation transmitted to the remote server may include indications ofinaccurate estimations driving durations native scheduling engine,indications of inaccurate estimations of task durations, and indicationsof inaccurate skill requirements per task. The native scheduling enginemay assign different task durations for a plurality of task types,different task durations for a plurality of field professionals,different task durations for a plurality of customer types, differenttask durations for time of day, different task durations for a pluralityof areas of task locations, different task durations for a plurality ofskills of the field professional, and more. In one embodiment, the localserver may update the native scheduling engine by changing at least onevalue of the plurality of scheduling parameters. For example, originallythe native scheduling engine of local server 3330B assumed it will takeBob 68 minutes to complete a certain task type. But using the updatednative scheduling engine the local server may determines that there is80% likelihood that it will take Bob 50 minutes to complete the task and20% likelihood that it will take Bob 60 minutes to complete the task.

In addition, the processing device may transmit to the remote serverdetails about the at least one task that the native scheduling enginehad scheduled in an unoptimized manner. The details about the at leastone task may include, for example, the task reference number, the timeand date of the task, the field professional assigned to the task, thelocation of the task, the customer associated with the task, and more.According to embodiments of the present disclosure, the processingdevice may also transmit to the remote server at least onerecommendation for optimizing scheduling of tasks by the nativescheduling engine. In one example, the at least one recommendation mayinclude a suggestion to reassign the task that the native schedulingengine had scheduled in an unoptimized manner to a different fieldprofessional. In another example, the at least one recommendation mayinclude a suggestion to reschedule the task that the native schedulingengine had scheduled in an unoptimized manner to a different time or adifferent date. In another example, the at least one recommendation mayinclude a warning. Specifically, the processing device may determine alikelihood that the at least one task that the native scheduling enginehad scheduled in an unoptimized manner will result in a failure tocomplete a task, and when the likelihood is greater than the threshold,the processing device may transmit a warning to the remote server.

Consistent with some embodiments, the processing device may obtain dataabout at least one environmental condition. The processing device mayobtain the data about at least one environmental condition from a datasource (e.g., data source 3350A). The term “environmental condition”refers to a condition that may have a physical effect on a dailyschedule of a field professional. The environmental condition mayinclude natural or man-made conditions. The natural environmentalconditions may include, for example, flood, hurricane, thunderstorm,earthquake, and more. The man-made environmental conditions may include,for example, atypical traffic conditions, construction, fires, and more.The processing device may determine a likelihood that the at least oneenvironmental condition was not accounted for by a current version ofthe native scheduling engine and transmit an update to a remote server(e.g., local server 3330A). In one example, the processing device maytransmit information for updating a current version of the nativescheduling engine.

Consistent with other embodiments, the processing device mayperiodically receive data associated with tasks scheduled by the nativescheduling engine. The term “periodically” in this context refers to thetransmission of data from the remote server being performed more thanonce or in successive instances and does not necessarily imply regularor uniform interval. For example, the processing device may receivefirst data associated with tasks scheduled by the native schedulingengine during a first time period (e.g., a week), and receive seconddata associated with tasks scheduled by the native scheduling engineduring a second time period (e.g., 10 days) subsequent the first timeperiod. The first and the second time period may or may not overlap. Inone example, the first time period and the second time period may bebetween one day and one hundred days. In some embodiments, a duration ofthe first time period may be selected such that a size of the first datais lower than a threshold associated with an ability of the at least oneprocessor to process in stateless manner. Specifically, the thresholdmay be determined based on a size of a RAM memory associated with the atleast one processor. For example, the size of the data received may beless than 100% of the size of the memory 3318, less than 90% of the sizeof the memory 3318, less than 75% of the size of the memory 3318, orless than 50% of the size of the memory 3318.

FIG. 38 depicts an exemplary method 3800 in accordance with anembodiment from the perspective of a local server (e.g., local server3330A). Method 3800 is used for scheduling tasks to field professionals.For purposes of illustration, the in the description of also thismethod, reference is made to certain components of system 3300. It willbe appreciated, however, that other implementations are possible andthat other components may be utilized to implement the exemplary method.It will also be readily appreciated that the illustrated method can bealtered to modify the order of steps, delete steps, or further includeadditional steps.

At step 3802, a processing device (e.g., processor 3340A) may receive aplurality of requests for on-site service from a plurality of users(e.g., users 130), wherein each request is associated with a differentlocation. At step 3804, the processing device may schedule a set oftasks from the plurality of requests using a native scheduling engine(e.g., native scheduling engine 3341A)). In one embodiment, theprocessing device may estimate travel durations between locationsassociated with the set of tasks. The travel durations of the fieldprofessionals may depend on accurate estimates of prevailing andemerging traffic conditions. As such, the processing device may utilizeadvanced traffic models to analyze traffic data, including real-timetraffic data and historical traffic data to estimate the traveldurations. Consistent with the present disclosure, different versions ofnative scheduling engine may use different scheduling data. Whendifferent versions of native scheduling engine are being used differentestimations of travel durations may be determined. For example, whenusing first scheduling data, native scheduling engine 3341A may estimatethat a specific ride will take 37 minutes, but when using secondscheduling data, native scheduling engine 3341A may estimate that aspecific ride will take 52 minutes.

In another embodiment, the processing device may estimate task durationsassociated with the set of tasks. As mentioned above, the task durationsmay be determined based on at least one of: the task type, the fieldprofessional, the customer type, the time of day, and the task area.Consistent with the present disclosure, when the native schedulingengine uses different scheduling data, different estimations of taskdurations may be determined. For example, a first version of nativescheduling engine 3341A may estimate that a specific task will becompleted in 25 minutes, but an updated second version of nativescheduling engine 3341A may estimate that the specific task will becompleted in 38 minutes. In other embodiments, the processing device maydetermine the requirements to complete each of the set of tasks andassign field professionals accordingly. The requirements may include theskills required to complete a task, the list of tools required tocomplete, and/or a list of parts required to complete. The requirementsmay also change when the native scheduling engine uses differentscheduling data.

At step 3806, the processing device may update the native schedulingengine based on information received from a remote server (e.g., centralserver 3805). In one embodiment, the information from a remote server Imay be received in response to sending the remote server data associatedwith the set of scheduled tasks (e.g., task data 3336A). This embodimentis described in detail with reference to steps 3704 to 3712 of FIG. 37.Alternatively, the information from a remote server may be receivedperiodically from the remote server. Alternatively, the information froma remote server may be received from the remote server after detecting atrigger: for example, after the remote server identifies anenvironmental condition that requires a change in the native schedulingengine. In addition, the processing device may receive from the remoteserver at least one recommendation for optimizing scheduling of futuretasks. In one example, the at least one recommendation may include asuggestion to reassign a task to a different field professional. Inanother example, the at least one recommendation may include asuggestion to reschedule a task to a different time or a different date.In another example, the at least one recommendation may include asuggestion associated with a desired scheduling weight. The desiredscheduling weight may be a value (e.g., a numeric, textual, alphabetic,or symbolic value) that indicates a level of desirability of schedulingcertain task types by local server 3330A.

At step 3808, the processing device may use the updated nativescheduling engine on the previously scheduled set of tasks to identify atask scheduled in an unoptimized manner. In a first embodiment, theprocessing device may use the updated native scheduling engine todetermine that a field professional assigned to a task is estimated toarrive at a location associated with the task before or after a timepreviously estimated by the processing device. For example, originallythe native scheduling engine had scheduled a first task to start at11:00 AM, but later the updated native scheduling engine determines thatthe first field professional assigned to the first task will not arriveto the location associated with the first task before 11:40 AM. In asecond embodiment, the processing device may use the updated nativescheduling engine to determine that a field professional assigned to atask is estimated to complete the task before or after a time previouslyestimated by the processing device. For example, originally the nativescheduling engine had reserved in the schedule 2.5 hours for completinga second task, but later the updated native scheduling engine determinesthat a second field professional assigned to the second task willcomplete the second task in less than an hour and may be available foran additional task. In a third embodiment, the processing device may usethe updated native scheduling engine to determine that a fieldprofessional assigned to a task does not have a skill set required tocomplete the task. For example, originally the native scheduling engineI had assigned a third field professional to a third task of installinga certain product, but later the updated native scheduling enginedetermines that the third field professional did not complete thetraining for installing that certain product.

At step 3810, the processing device may cause a schedule changeassociated with the identified task. In one embodiment, the identifiedtask was previously assigned to a first field professional and causingthe schedule change may include reassigning the identified task to asecond field professional. For example, with reference to the lowerschedule in FIG. 35, the task identified as being scheduled in anunoptimized manner was task 3532 and the schedule change may includereassigning task 3532 from Donald to Bruce. In another embodiment, theidentified task was previously assigned to a first field professionaland causing the schedule change may include reassigning a different taskpreviously assigned to the first field professional to a second fieldprofessional thereby enabling the first field professional to completethe identified task. For example, with reference to the lower schedulein FIG. 35, the task identified as being scheduled in an unoptimizedmanner was task 3523 and the schedule change may include reassigningtask 3524 from Chuck to Arnold. In another embodiment, the identifiedtask is scheduled at a certain time and causing the schedule change mayrequire rescheduling the identified task to a different time. Forexample, with reference to the lower schedule in FIG. 35, the taskidentified as being scheduled in an unoptimized manner was task 3514 andthe schedule change may include rescheduling task 3514 to a differenttime. In a related embodiment, rescheduling the identified task to adifferent time may include suggesting a user one or more alterativetimes selected by the updated native scheduling engine.

Consistent with the present disclosure, the processing device mayperiodically transmit to the remote server (e.g., central server 3805)data associated with a plurality of scheduled tasks. As mentioned above,this data is used by an optimization engine to determine the informationthat may be used for updating the native scheduling engine. In someembodiments, the size of the periodically transmitted data may be lessthan a threshold to enable processing the data in stateless manner.Specifically, the threshold may be determined based on a size of a RAMmemory associated with the at least one processor of the remote server.For example, the size of the data received may be less than 100% of thesize of the memory 3318, less than 90% of the size of the memory 3318,less than 75% of the size of the memory 3318, or less than 50% of thesize of the memory 3318.

M. Assigning Tasks Based on Real-Time Conditions

A scheduling system should take into consideration real-time conditionsthat affect a schedule for a field professional. These real-timeconditions may include an unplanned event likely to interfere with thefield professional completing a task (e.g., user cancellation of anappointment, malfunction of a tool, traffic, etc.), and a window ofopportunity for scheduling additional tasks to the field professional(e.g., shorter-than-estimated travel durations, shorter-than-estimatedtask durations, user cancellation of an appointment, etc.). Uponconsidering the real-time conditions, the disclosed system may identifyseveral optional tasks that may be assigned to the field professional.In a first embodiment, the system may present the optional tasks to thefield professional and assign a task based on the field professional'sselection. FIGS. 40A and 40B illustrate user interfaces associated withthe first embodiment. In a second embodiment, the system may use anartificial intelligence technology on historical data that may beindicative of dispatchers' preferences to identify possible tasks toassign to the field professional, to identify a group of fieldprofessionals as candidates for doing certain tasks, or to learn details(e.g., skills) on the field professionals. FIG. 41 illustrates softwaremodules associated with the second embodiment.

The following disclosure describes how system 100 dynamically changesthe schedule of field professionals based on real-time information. Asused herein, the term real-time information may refer to information ordata collected at the time an event occurs or soon after the eventoccurs. The real-time information may include data relevant todetermining the capability or the progress of a field professional's inarriving at a location associated with a task at a scheduled time and/orin completing on-site services associated with scheduled tasks. Thereal-time information may be collected from at least one source, suchas, but not limited to, a mobile device (e.g., a mobile telephone, apersonal digital assistant (PDA), a laptop computer, a tablet computer),an IoT device (e.g., including at least one of: a temperature sensor, abarometer, an altimeter, a visible light sensor), a global positioningsystem (GPS), a radio beacon, a wireless local area network (WLAN)station, a vehicle information and communication system (VICS), atraffic information broadcast system, a vehicle tracking and telemetrysystem, a weather monitoring system (WMS), social network and newswebsites, and more. In one embodiment, the real-time information mayreflect location information associated with the field professional.Based on the location information, system 100 (alone or with referenceto other internal or external systems) may determine if a fieldprofessional is at a location associated with one of the tasks in theschedule or en route to a scheduled task. In another embodiment, thereal-time information may reflect task updates (e.g., field professional110 may use a dedicated communication device or a dedicated applicationto provides real-time updates, such as “arrived at destination” and “5minutes delay in completing the task”). In yet another embodiment, thereal-time information may include updates from different data sourcesoutside system 100 that may affect the progress of field professional110 (e.g., traffic updates, weather updates, user's social profiles,etc.).

Consistent with the present disclosure, the real-time information mayreflect required changes to a schedule of a field professional. Asdiscussed below with reference to FIG. 39A, system 100 may determine,from the real-time information, existence of an unplanned event likelyto interfere with the field professional completing at least one taskfrom the daily schedule. In addition, as discussed below with referenceto FIG. 39B, system 100 may determine, from the real-time information, awindow of opportunity to assign an additional task to the fieldprofessional.

FIG. 39A depicts a planned timeline and an actual timeline of a firstfield professional 110 (e.g., Bart). Originally, as illustrated in theplanned timeline, Bart was assigned with five tasks: task A (scheduledto start at 8:30 AM and estimated to end at 9:30 AM), task B (scheduledto start at 10:00 AM and estimated to end at 11:00 AM), task C(scheduled to start at 11:30 AM and estimated to end at 12:30 PM) task D(scheduled to start at 1:00 PM and estimated to end at 2:00 PM), andtask E (scheduled to start at 2:30 PM and estimated to end at 3:00 PM).In FIG. 39A, each of the tasks that Bart was assigned to is associatedwith a different location, and the planned timeline includes periods oftime between the tasks that correspond to the estimated travel durationtimes.

In the actual timeline, it is shown that Bart had completed tasks A andB according to the planned schedule, and encountered an unplanned event3900 on the way to a location associated with task C. In the followingexample, unplanned event 3900 is a flat tire, but a person skilled inthe art would recognize that there may be nearly unlimited differenttypes of unplanned events that may interfere with the fieldprofessional's work and may prevent completion of one or more scheduledtasks. Steps 3902 to 3908 may be implemented by system 100 after Barthad encountered unplanned event 3900. At step 3902, system 100 mayreceive real-time information associated with Bart. In this example, thereal-time information may include a message from Bart that he had a flattire. At step 3904, system 100 may determine existence of an unplannedevent likely to interfere with task C. For example, system 100 mayestimate that it will take Bart 20 minutes to fix the flat tire, andbased on the current traffic conditions, he is expected to arrive to thelocation associated with task C around 11:50 AM. Thus, the flat tireevent is likely to interfere with task C scheduled to start at 11:30 AM.Accordingly, system 100 may reassign task C to a different fieldprofessional or reschedule task C to a different date. System 100 mayidentify a group of optional tasks (e.g., task F, task G, task H, taskI, and task J). The optional tasks may include repair and maintenanceservices of IoT devices or different location-agnostic tasks. At step3906, system 100 may present Bart some of the identified tasks (e.g.,task F, task G, task H) as alternatives to task C. At step 3908, upondetecting Bart's selection, system 100 may assign Bart with task F.After Bart has completed task F, he can continue with his plannedschedule and complete tasks D and E.

FIG. 39B depicts a planned timeline and an actual timeline of a secondfield professional 110 (e.g., Lisa). Originally, as illustrated in theplanned timeline, Lisa was assigned with five tasks: task A (scheduledto start at 8:30 AM and estimated to end at 9:30 AM), task B (scheduledto start at 10:00 AM and estimated to end at 11:45 AM), task C(scheduled to start at 12:45 PM and estimated to end at 1:30 PM) task D(scheduled to start at 2:00 PM and estimated to end at 3:00 PM), andtask E (scheduled to start at 3:30 PM and estimated to end at 4:30 PM).In FIG. 39, each of the tasks that Lisa was assigned to is associatedwith a different location, and the planned timeline includes periods oftime between the tasks that correspond to the estimated travel durationtimes.

In the actual timeline, it is shown Lisa had completed task A accordingto the planned schedule and completed task B much earlier thanestimated. Consequently, a window of opportunity 3950 had opened. In thefollowing example, window of opportunity 3950 was instigated when Lisacompleted task B earlier than estimated, but a person skilled in the artwould recognize that there may be other causes and/or combination ofcauses responsible for windows of opportunity. For example, a customermay cancel an appointment, the travel duration takes less time thanestimated, and more. Steps 3952 to 3958 may be implemented by system 100after Lisa has completed task B. At step 3952, system 100 may receivereal-time information about Lisa's progress. For example, Lisa may use adedicated application on her smartphone to provide a real-time update“task completed.” At step 3954, system 100 may determine a window ofopportunity. Determining the window of opportunity may includedetermining a duration of the window of opportunity. At step 3956,system 100 may identify a plurality of optional tasks (e.g., task F,task G, and task H). At step 3908, system 100 may automatically selecttask F and assign it to Lisa. After Lisa has completed task F, she cancontinue with her planned schedule and complete tasks D and E.

FIGS. 40A and 40B depict two graphical user interfaces (GUIs) accordingto embodiments of the present disclosure. The GUIs may be part of adedicated app installed in field professional communication device 180A.Specifically, FIG. 40A depicts a GUI 4000 that enables fieldprofessional 110 to provide real-time information to system 100; andFIG. 40B depicts a GUI 4010 that enables field professional 110 toselect an optional task from a list of optional tasks identified bysystem 100.

GUI 4000 in FIG. 40A may include a map area displaying a currentlocation of field professional 110 relative to the location associatedwith a next task in the daily schedule. GUI 4000 may also present theestimated time of arrival for the next task's location. Below the maparea, GUI 4000 displays the fields “Next Task,” “Current Status,” and“Event Type.” The field “Next Task” may present the next task's IDnumber. Field professional 110 may obtain additional details on the nexttask by pressing the ID number. For example, the additional details thatGUI 4000 may present to field professional 110 may include: informationabout the customer (e.g., name, address, phone number, etc.),information about the scheduled on-site service (type of service,required parts, etc.), and more. The field “Current Status” may beautomatically completed by the system, for example, based on locationdata received from communication devices 180A. Alternatively, the field“Current Status” may be manually completed by field professional 110 byentering updates such as: “arrived at location,” “task completed,” andmore. The field “Event Type” may include details on an unplanned eventlikely to interfere with at least one task from the daily schedule. Inone embodiment, the details may include a time estimation of theexpected delay due to the unplanned event. GUI 4000 may also include a“send” button for transmitting the event reporting to system 100.

GUI 4100 in FIG. 40B may present to field professional 110 a list ofoptional tasks identified by system 100. In one embodiment, fieldprofessional 110 may be prompt to select an optional task from the listwhen system 100 determines existence of an unplanned event likely tointerfere with a task from the daily schedule. In another embodiment,field professional 110 may be prompt to select an optional task from thelist when system 100 determines a window of opportunity to assign anadditional task to the field professional. GUI 4010 may include afeature 4012 to refresh the list, as some of the optional tasks may beconcurrently scheduled by the system, by dispatchers, or by other fieldprofessionals. Field professional 110 may change the presentationparameters of the list of optional tasks identified by system 100. Forexample, GUI 4010 may include a feature 4014 for sorting the pluralityof optional tasks. In FIG. 40B the optional tasks are sorted based ontheir distance, i.e., the distance of a location of an optional taskfrom a current location of field professional 110. A person skilled inthe art would recognize that field professional 110 may be able to sortthe plurality of optional tasks according to other parameters, forexample, based on task type (e.g., location-agnostic tasks orlocation-based tasks), based on client type (e.g., private customers orindustrial customers), based on estimated task duration, based on duedate, and more.

FIG. 41 illustrates a memory 4100 containing software modules anddatabases consistent with the present disclosure. In some embodiments,memory 4100 may be part of server 152. Alternatively, memory 4100 may bestored in an external storage communicatively coupled with server 152,such as one or more databases or memories accessible over network 170.Further, in other embodiments, the components of memory 4100 may bedistributed in more than one server. As shown, memory 4100 may includean input module 4102, an optional task identification module 4104, atask selection module 4106, and an output module 4108. Modules 4102,4104, 4106, and 4108 may contain software instructions for execution byat least one processing device (e.g., processor 202). Memory 4100 mayalso include or be connected to a plurality of databases, such as apending requests database 4110 which may store details on requests foron-site services (e.g., requests that were not yet scheduled); a fieldprofessionals database 4112 which may store data on each fieldprofessional (e.g., skills, qualifications, experience, shifts times,ranking); and a historical assignment database 4114 which may store dataassociated with assignments of tasks for a plurality of fieldprofessionals when windows of opportunity are identified. For example,historical assignment database 4114 may store data indicative of pastdispatchers' preferences regarding assignments of additional tasks.

Consistent with the present disclosure, input module 4102, optional taskidentification 4104, task selection module 4106, and output module 4108may cooperate to perform multiple operations. For example, input module4102 may provide to optional task identification 4104 an identificationof a window of opportunity associated with a specific fieldprofessional. Optional task identification 4104 can interact withpending requests database 4110, field professionals database 4112, andan external data source 4116 configured to store updated information,such as traffic conditions, weather conditions, etc. In oneimplementation, optional task identification 4104 can process theaccessed data and forward to task selection module 4106 details ofplurality of optional tasks that the specific field professional cancomplete during the window of opportunity. Task selection module 4106can interact with field professionals database 4112 and historicalassignment database 4114, and select which task assign to the specificfield professional. Output module 4108 may receive an identification ofthe selected task from task selection module 4106 and may change thedaily schedule of the specific field professional accordingly.

Input module 4102 can receive a set of requests for on-site service froma plurality of users and receive real-time information about a progressof a field professional assigned to a set of tasks associated with asubset of requests. The requests for the on-site services may beassociated with different locations. In a case where input module 4102is part of server 152, input module 4102 can receive the real-timeinformation via network interface 206 transmitted from one or morecommunication devices (e.g., field professional communication device180A, customer service communication device 1808, or user communicationdevice 180C). In some embodiments, the real-time information about theprogress of a specific field professional may reflect the likelihoodthat the specific field professional will complete the daily schedule ofassigned tasks. Based on the real-time information, input module 4102may determine existence of an unplanned event likely to interfere withthe specific field professional completing at least one task from thedaily schedule. In addition, input module 4102 may determine existenceof a window of opportunity to assign an additional task to the specificfield professional. The window of opportunity may (or may not) beassociated with the unplanned event. Input module 4102 can then transmitdata identifying the determined window of opportunity associated with aspecific field professional to optional task identification module 4104for processing.

Optional task identification module 4104 may receive the dataidentifying the determined window of opportunity from input module 4102and detect a plurality of optional tasks for the specific fieldprofessional. Optional task identification module 4104 may accesspending requests database 4110 to learn which tasks are available forscheduling. The tasks available for scheduling may include tasksassociated with unassigned requests and tasks that were scheduled todeferred dates due to lack of field professionals' availability.Thereafter, optional task identification module 4104 may apply one ormore criteria for determining a plurality of optional tasks relevant forthe specific field professional. In one embodiment, the one or morecriteria may include distance of a task's location to a current locationof the specific field professional. In another embodiment, the one ormore criteria may include the current traffic conditions along a routeto a task's location. In another embodiment, the one or more criteriamay include the current weather conditions at a task's location. Inanother embodiment, the one or more criteria may include skills of thespecific field professional. In another embodiment, the one or morecriteria may include a scheduling weight indicating a desired ratiobetween the types of scheduled tasks. In another embodiment, the one ormore criteria may include details associated with the tasks and/ordetails associated with the customer (e.g., only IoT device customers).In another embodiment, the one or more criteria may include a predictedtask duration. The predicted task duration may be used by the system todetermine if a task should be offered to a field professional. Forexample, the system may determine that a first field professional may beassigned to a certain task since the predicted duration for him would be60 minutes while a second field professional may not be assigned to thecertain task as the system estimates the predicted duration for himwould be 75 minutes.

Task selection module 4106 may receive the data identifying theplurality of optional tasks from optional task identification module4104 and select at least one of the plurality of optional tasks forassignment. Task selection module 4106 may select the at least oneoptional task by processing of information using artificial intelligence(AI) technology and Machine learning (ML) technology. Specifically, taskselection module 4106 may include AI software instructions that enable aprocessing device to perform at least one of learning of information,inference of information, and perception of information. Moreover, taskselection module 4106 may include ML software instructions that enable aprocessing device to process a large amount of information (big data),such as information stored in an associated database (e.g., historicalassignment database 4114). Using the AI and ML technologies, taskselection module 4106 can process a large amount of information toselect at least one of the plurality of optional tasks for assignment.The processing of information is an operation that graspscharacteristics, rules, and judgment criteria of information, quantifiesrelationship between information and information, and predicts new datausing a quantified information. Task selection module 4106 may identifyat least one optional task that the field professional may be able tocomplete during the window of opportunity, based on the patterns learnedby processing the information. For example, task selection module 4106may determine a pattern associated with past dispatchers' preferencesregarding assignment of additional tasks and may select the at least oneoptional task based on the determined pattern. In one embodiment, taskselection module 4106 may also rank the plurality of optional tasks thatthe field professional can complete during the window of opportunityaccording to a likelihood that a human dispatcher would select eachtask. Task selection module 4106 can then transmit data identifying theat least one optional task to output module 4108 for processing.

Output module 4108 can determine whether to automatically assign thespecific field professional to the at least one task selected by taskselection module 4106. In case task selection module 4106 had identifieda group of optional tasks that meet the selection criteria, outputmodule 4108 can determine to present the group of optional tasks to thespecific field professional and to prompt the specific fieldprofessional to choose an optional task. Upon assigning an additionaltask to the specific field professional, output module 4108 may updatehistorical assignment database 4114 to reflect the selected taskassignment.

FIG. 42 is a flowchart of an example process 4200 for scheduling tasksto field professionals executed by a processing device of system 100,according to embodiments of the present disclosure. For purposes ofillustration, in the following description, reference is made to certaincomponents of system 100. It will be appreciated, however, that otherimplementations are possible and that other components may be utilizedto implement the exemplary method. It will also be readily appreciatedthat the illustrated method can be altered to modify the order of steps,delete steps, or further include additional steps.

At step 4202, a processing device (e.g., processing device 202) providesa field professional information about a daily schedule of assignedtasks associated with a set of requests for on-site services. At step4204, the processing device receives real-time information reflecting alikelihood the field professional will complete the daily schedule ofassigned tasks. Consistent with the present disclosure, the processingdevice may receive the real-time information from a customer serviceunit (e.g., customer service unit 120), from a user device (e.g., thecustomer's communication device 180C), or from a field professionaldevice (e.g., communication device 180A). For example, when thereal-time information is associated with an event of a user'scancellation of an appointment, the real-time information may bereceived from any of the communication devices mentioned above.Specifically, users may call to the customer service unit and informthat they need to cancel the appointment; users may interact with system100 directly via a website that has a feature to cancel appointments(e.g., a link to the website may be provided to the users by system100); users may interact with system 100 by responding to a message(e.g., a verification SMS, email or Interactive voice response (IVR)message with a cancellation request; and the field professional may callthe user and learn that the user forgot about the appointment.Thereafter, the field professional may use a dedicated app to cancelthis appointment.

At step 4206, the processing device determines from the real-timeinformation existence of an unplanned event likely to interfere with thefield professional completing at least one task from the daily schedule.The unplanned event may have been resulted from a situation associatedwith the user, from a situation associated with the field professional,or from environmental conditions. In one embodiment, the unplanned eventmay include user cancellation of an appointment associated with a taskin the daily schedule of the field professional. For example, when theuser is stuck at work and cannot make it home in time for theappointment with the field professional. In another embodiment, theunplanned event may include a significant delay of the fieldprofessional to the appointment with the user. For example, when thefield professional had a flat tire on the way to a location associatedwith a next task and expected to be 30 minutes late. In anotherembodiment, the unplanned event may include atypical traffic conditionsassociated with a driving route to a location of a task in the dailyschedule of the field professional. For example, when the driving routehad a road blocked for repair and the field professional or the userwill not be able to get in time to the location associated with theappointment. In this embodiment, the real-time information associatedwith the atypical traffic conditions may be received from trafficcontrol services or directly from the field professional. In anotherembodiment, the unplanned event may include atypical weather conditionsat a location associated with a task in the daily schedule of the fieldprofessional. Examples for atypical weather conditions may include heavyrain, heat wave, a hurricane, flooding, and more. The atypical weatherconditions may prevent the field professional from getting to thelocation associated with the appointment or prevent the fieldprofessional from completing the task. In another embodiment, theunplanned event may include lack of parts associated with a task in thedaily schedule of the field professional. For example, when the fieldprofessional had used unexpectedly a replacement part that was plannedto be used in a future task, and now a scheduled task cannot becompleted. In another embodiment, the unplanned event may include amalfunction of a tool needed for completion of a task in the dailyschedule of the field professional. For example, when a tool needed in ascheduled task unexpectedly broke in a previous task.

At step 4208, the processing device identifies and present a pluralityof optional tasks to the field professional based on the determinationat step 4206. In identifying the plurality of optional tasks, theprocessing device may access at least one database of unscheduled tasks(e.g., tasks associated with recent requests) or scheduled tasks thatmay be rescheduled on-the-fly (e.g., repair and maintenance services forIoT devices). The plurality of optional tasks may include at least onelocation-agnostic task that includes a remote communication session witha customer (e.g., remote support session) and at least onelocation-agnostic task that does not involve communicating withcustomers (e.g., completing reports of past tasks). In order to presentthe field professional with the most relevant available tasks, theprocessing device may filter one or more irrelevant tasks. In oneembodiment, the processing device may identify the plurality of optionaltasks by taking into account a specific skill set of the fieldprofessional and confirming that the field professional is capable toperform each assignment of the plurality of optional tasks. In anotherembodiment, the processing device may identify the plurality of optionaltasks by taking into account a current location of the fieldprofessional and confirm that each location associated with theplurality of optional tasks is within a predefined distance from thecurrent location of the field professional (e.g., less than five miles).In another embodiment, the processing device may identify the pluralityof optional tasks by considering traffic conditions (e.g., current andpredicted traffic conditions) and estimate how much each assignment ofthe plurality of optional tasks would affect the rest of the dailyschedule of the field professional. In addition, the processing devicemay rank the plurality of optional tasks based on the differentconsiderations discussed above, and present only a part of the pluralityof optional tasks based on their ranking. For example, a task associatedwith a closer location may have a higher ranking.

At step 4210, the processing device assigns the field professional to aselected task and unassign the at least one task. In a first embodiment,unassigning the at least one task may include rescheduling the at leastone task to a different time. Consistent with the first embodiment, theprocessing device may determine existence of an unplanned event likelyto interfere with the field professional completing a single task fromthe daily schedule and reschedule the single task to a different time.For example, the single task may be scheduled to a different day basedon the field professional's availability and/or the customer'savailability. In a second embodiment, unassigning the at least one taskmay include assigning the at least one task to a different fieldprofessional. Consistent with the second embodiment, the processingdevice may determine existence of an unplanned event likely to interferewith the field professional completing a single task from the dailyschedule and reassign the single task to another field professional. Forexample, the on-site service associated with the at least one task maybe provided to the user at the scheduled time, but by a different fieldprofessional. In some cases, the processing device may determineexistence of an unplanned event likely to interfere with the fieldprofessional completing a plurality of tasks from the daily schedule.For example, the field professional may be involved in a car accident onthe way to a first task of the day. In these cases, the processingdevice may reschedule at least some of the plurality of task todifferent dates and/or reassign at least some of the plurality of tasksto different field professionals.

FIG. 43 depicts an example method 4300 for scheduling tasks to fieldprofessionals executed by a processing device of system 100, accordingto embodiments of the present disclosure. For purposes of illustration,in the following description, reference is made to certain components ofsystem 100. It will be appreciated, however, that other implementationsare possible and that other components may be utilized to implement theexemplary method. It will also be readily appreciated that theillustrated method can be altered to modify the order of steps, deletesteps, or further include additional steps.

At step 4302, a processing device (e.g., processing device 202) receivesa set of requests for on-site service, each request may be associatedwith a different location. The set of requests for on-site service mayinclude at least one request received from a user (e.g., user 130) andat least one request received from an IoT device (e.g., IoT device 140)without any user intervention. At step 4304, the processing device mayreceive real-time information about a progress of a field professionalassigned to a set of tasks associated with a subset of requests. In oneembodiment, the processing device may receive real-time information froma communication device associated with the field professional. Forexample, the field professional may use a dedicated application or adedicated communication device to provide real-time updates, such as“arrived location,” “task completed,” and more. In another embodiment,the processing device may receive real-time information from a deviceassociated with the on-site service. For example, the processing devicemay receive updates directly from an IoT device being repaired.

At step 4306, the processing device dynamically determines a window ofopportunity to assign an additional task to the field professional.Consistent with the present disclosure, the processing device maydetermine the window of opportunity from real-time information thatincludes traffic conditions in a geographic area associated with acurrent location of the field professional. The traffic conditions mayinclude real-time traffic conditions and predicted traffic conditions.In another embodiment, the processing device may determine the window ofopportunity from real-time information that includes task status updatestransmitted from a communication device of the field professional. Inanother embodiment, the processing device may determine the window ofopportunity from real-time information that includes current locationinformation derived at least partially from a location circuitcommunication device of the field professional. In another embodiment,the processing device may determine the window of opportunity fromreal-time changes in the daily schedule of the field professional. Inanother embodiment, the processing device may determine the window ofopportunity from a user cancellation of a task in a daily schedule ofthe field professional. In another embodiment, the processing device maydetermine the window of opportunity from a completion of a task in adaily schedule of the field professional faster than estimated. Thisembodiment is illustrated in FIG. 39. In another embodiment, theprocessing device may determine the window of opportunity from arrivingat a location associated with a task in a daily schedule faster thanestimated. In another embodiment, the processing device may determinethe window of opportunity from reassignment of a task in a dailyschedule of the field professional to a different field professional.

In order to identify windows of opportunity, the processing mayperiodically check if there are differences between estimated conditions(e.g., traffic conditions, work progress, etc.) and the currentconditions. For example, when the daily schedule of a field professionalwas determined, the estimated task duration of task A was estimated tobe 30 minutes, and the travel duration between the location associatedwith task A and the location associated with task B was estimated to be45 minutes. Upon arriving at the location associated with task A, thefield professional updates the processing device that the on-siteservice associated with task A would be completed in 10 minutes.Thereafter, the processing device may determine, based on the real-timetraffic conditions and the current location of the field professional,that the travel duration from the location associated with task A andthe location associated with task B would take only 20 minutes. Thus,the field professional will have a window of 45 minutes before task Bstarts.

At step 4308, the processing device identifies a plurality of optionaltasks that the field professional is determined to be able to completeduring the window of opportunity. In some embodiments, to identify theplurality of optional tasks, the processing device may check if thefield professional can start one of the tasks associated with the subsetof requests earlier than a scheduled time. Checking if the fieldprofessional can start a task earlier may include asking a customerassociated with the task or identifying that completing the task doesnot require a presence of a user (e.g., repairing an IoT device that isnot located within a user's property). With reference to the exampleabove, the processing device may receive a confirmation from customerassociated with task B that the field professional can start task Bearlier. In other embodiments, the real-time information may include acurrent location of the field professional and traffic conditions in thegeographic area. The processing device may use the traffic conditions inthe geographic area and the current location of the field professionalto identify the plurality of optional tasks. For example, the processingdevice may follow rules for identifying optional tasks, such as onlylocation-agnostic tasks, tasks within five miles radius from the currentlocation of the field professional, or tasks within 15 minutes' drivefrom the current location of the field professional. The rules may beassociated with the duration of the window of opportunity. For example,when the window of opportunity is more than 60 minutes, allow up to 15minutes' drive, but when the window of opportunity is less than 45minutes, allow up to 10 minutes' drive.

At step 4310, the processing device automatically selects one of theoptional tasks for assignment to the field professional based onhistorical data. Consistent with the present disclosure, the processingdevice may be associated with a memory device (e.g., database 154)configured to store historical data indicative of past dispatchers'preferences regarding assignment of additional tasks. The memory devicemay also store historical data indicative of past field professionals'preferences regarding assignment of additional tasks. For example, thereceived selection of the field professional as described in step 4210above. In some embodiments, the historical data may include details on aplurality of past windows of opportunity, and the at least one processoris configured to identify a past window of opportunity similar to acurrent window of opportunity, and to select the task based on the pastdispatchers' preferences regarding assignment of a task associated withthe past window of opportunity. The details on the plurality of pastwindows of opportunity may include times, durations, information aboutthe field professionals associated with the plurality of past windows ofopportunity (e.g., skills, experience, working hours, etc.), andinformation about the optional tasks that each of the fieldprofessionals could have completed during a corresponding past window ofopportunity. In additional embodiments, the processing device maydetermine a pattern associated with the past dispatchers' preferencesregarding assignment of additional tasks, and select the task based onthe determined pattern. For example, the processing device may determinethat an hour before shift ends, a human dispatcher always selects alocation-agnostic task. In addition, the processing device may rank theplurality of optional tasks that the field professional can completeduring the window of opportunity according to a likelihood that a humandispatcher would select each task. The ranking of the plurality ofoptional tasks may also be based on other parameters to enable greateroptimization of scheduling of tasks for all the field professionals.

At step 4312, the processing device assigns the field professional tothe selected task. In one embodiment, the selected additional task maybe a location-agnostic task associated with a request for remoteassistance received before the window of opportunity. Specifically, theselected additional task may be being available to provide at least onelocation-agnostic service for requests received during the window ofopportunity. In another embodiment, the selected additional task may bea location-based task associated with a location in proximity to acurrent location of the field professional (e.g., less than a mile). Inaddition, the selected additional task may be one that is estimated toend before the field professional is required to start driving towards alocation of a next scheduled task. For example, with reference to theexample illustrated in FIG. 39, task F is estimated to end before Lisaneeds to start driving towards a location associated with task C.

N. Tasks Scheduling Using Connected Devices

The Internet of Things (IoT) has grown well beyond smart watches andsecurity cameras. In fact, the IoT trend is changing the future ofbusiness with its now billions of “things.” Some of these things havesensors for monitoring other things. While many IoT devices have thefunctionality of alerting users when a malfunction occurs or ispredicted to occur, they still rely on their users to repair them orrepair the things they monitor. The following disclosure provides asolution that will enable IoT devices to autonomously schedule on-siteservice, for example, without any user intervention.

Consistent with the present disclosure, a system that schedules tasks tofield professionals (e.g., system 100) may receive a request from aconnected device that includes an indication of an urgency level. Thesystem may take into consideration other requests (e.g., from humancustomers) and schedules a visit of a field professional within a timeperiod that corresponds with the urgency level. The urgency level can bedetermined from information derived from the connected device and thescheduled visit (e.g., for repair or maintenance) may be given aprecedence in the task schedule relative to other previously scheduledtasks. In one example, the connected device may periodically sendperformance data to a server, the server may analyze the performancedata, determine that maintenance service is in needed, and causescheduling of an on-site service (the server may or may not be part ofthe system that assigns tasks to field professionals). In anotherexample, the connected device may monitor a living being (e.g., elderlypeople, livestock), and may cause scheduling of a visit of a health careprovider without an approval of the monitored being.

As used herein, terms like “connected device” or “IoT device” refer toany device (e.g., an appliance, a sensor, etc.) that has an addressableinterface (e.g., an Internet protocol (IP) address, a Bluetoothidentifier (ID), a near-field communication (NFC) ID, etc.) that cantransmit information, for example, to a processing device (e.g.,processing device 202) using a network such as a local ad-hoc network orthe Internet. A connected device may have a passive communicationinterface, such as a quick response (QR) code, a radio-frequencyidentification (RFID) tag, an NFC tag, or the like, or an activecommunication interface, such as a modem, a transceiver, atransmitter-receiver, or the like. The connected device may have aparticular set of attributes (e.g., a device state or status, such aswhether the connected device is on or off, open or closed, idle oractive, available for task execution or busy, a cooling or heatingfunction, an environmental monitoring or recording function, alight-emitting function, a sound-emitting function, etc.) that can beembedded in and/or controlled/monitored by a central processing unit(CPU), microprocessor, or the like. Consistent with the presentdisclosure, a connected device can encompass the range from the simplestIoT devices to the most robust legacy Internet accessible devices. Forexample, connected devices may include, but are not limited to,refrigerators, toasters, ovens, microwaves, freezers, dishwashers,dishes, hand tools, clothes washers, clothes dryers, furnaces, airconditioners, thermostats, televisions, light fixtures, vacuum cleaners,sprinklers, electricity meters, gas meters, thermometers, humiditysensors, soil sensors, security cameras, motion detection lights,traffic sensors, wearable devices, fitness bracelets, continuous glucosemonitor devices, connected inhalers, an ingestible sensors, coagulationtesting devices, asthma monitor devices, cell phones, desktop computers,laptop computers, tablet computers, personal digital assistants (PDAs),etc.

FIG. 44 is a diagram showing a timeline 4400 illustrating thechronological events that happen when a processing device (e.g.,processing device 202) schedules a first request from a human customerand a second request from a connected device to at least one fieldprofessional, according to disclosed embodiments. As illustrated,timeline 4400 includes a splitting point 4414 to two optional timelines(First Time Period and Second Time Period) that correspond with theurgency level of the second request of the connected device. The mannerand order in which events are shown in timeline 4400 are chosen forconvenience and clarity of presentation and is not intended to limit thedisclosed embodiments.

Initially, at step 4402, a processing device may receive a first requestfor a service. The requested service may be a location-based service(e.g., it may include a repair of a device in a customer's house) or alocation-agnostic service (e.g., it may include remote accessing acustomer's device). According to some embodiments of the presentdisclosure, the first request may be autonomously received from aconnected device; but in the example illustrated in FIG. 44, the firstrequest is received from a human customer. Thereafter, at step 4404, theprocessing device may schedule a first task for providing the requestedservice to the human customer. In the illustrated example the processingdevice scheduled the task associated with the first request on date “A.”

At step 4406, the processing device may receive a second request for aservice. The service autonomously requested by the connected device mayalso be a location-based service (e.g., it may include a repair of theconnected device or a repair of a device monitored by the connecteddevice) or a location-agnostic service (e.g., it may include updating asoftware or fixing a bug). In cases where the first request is also froma connected device, the connected devices associated with the first andsecond requests may be from different types or associated with differentowners. At step 4408, the processing device may determine an urgencylevel associated with the second request. The term “urgency level” asused herein refers to a determination of the need of the connecteddevice for the service so that the connected device can continuefunctioning without sacrificing performance. In some cases, theconnected device may include in the request an indicator of the urgencylevel. In other cases, the connected device may include data (e.g.,measurements, reports, etc.) in the request and the processing devicewill derive from the received data the urgency level. At step 4410, theprocessing device may determine a time period that corresponds with theurgency level. In the figure, the first optional time line illustrates acase where the determined time period ends after date “A,” and thesecond optional time line illustrates a case where the determined timeperiod ends before date “A.” At step 4412, the processing device mayschedule a second task associated with the second request from theconnected device to date “B.” In the illustrated example date “B” may bebefore date “A,” after date “A,” or on the same day.

In one embodiment, illustrated in the first optional timeline aftersplitting point 4414, the processing device may schedule a taskassociated with the second request at the second scheduled date (date“B”) being after the first scheduled date (date “A”). This optionaltimeline describes a case when the time period that corresponds with theassociated urgency level ends after the first scheduled date (date “A).In another embodiment, illustrated in the second optional timeline aftersplitting point 4414, the processing device may schedule a taskassociated with the second request at the second scheduled date (date“B”) being before the first scheduled date (date “A). This optionaltimeline describes a case when the time period that corresponds with theassociated urgency level ends before the first scheduled date (date “A).In yet another embodiment, not shown in the figure, the processingdevice may schedule the task associated with the second request at thefirst scheduled date, for example, the task associated with the secondrequest may be scheduled instead of the task associated with the firstrequest. This scenario may occurred when the urgency level associatedwith the request of the connected device is higher than a threshold. Inthis scenario, the processing device may reschedule the task associatedwith the first request to a different date. In some embodiments, theprocessing device may prefer to reschedule tasks of connected devices(rather than rescheduling tasks of human customers) to a different datewithin their corresponding determined time periods.

At step 4416, which takes place on date “A,” a field professional mayprovide the service associated with first request, and at step 4418, theprocessing device may receive a confirmation that the first task hasbeen completed. Similarly, at step 4420, which takes place on date “B,”a field professional may provide the service associated with the secondrequest, and at step 4422, the processing device may receive aconfirmation that the second task has been completed. The decisionwhether the second task should be scheduled for a date before or afterdate “A,” may be based on the determined time period that is associatedwith the urgency level of the connected device.

FIG. 45 shows five locations (4500, 4502, 4504, 4506, 4508) associatedwith tasks that were previously scheduled in response to a first set ofrequests. Each of these task is associated with different task details(request date, task estimated duration, task scheduled date assigned tofield professional, and customer type). On June 6^(th), the systemreceived a second request from a connected device for an on-site serviceat another location (4510) in proximity to the first five locations(4500, 4502, 4504, 4506, 4508). In one example, the determined timeperiod associated with the second request is five days. For efficiencyreasons, the system may aim to schedule nearby tasks on the same dateand to the same field professional. Accordingly, the processing devicemay identify optional pending tasks associated with a location inproximity to the location associated with the second request. Forexample, the on-site service associated with the second request may bescheduled on the same date as the on-site services scheduled forlocations 4500, 4504, and 4506. The on-site services for locations 4502and 4508 are scheduled on dates later than the determined time period.

Consistent with the present disclosure, the processing device maydetermine, based on the time period, that the on-site service for theconnected device can be scheduled on a particular day when a firstrequest is scheduled. Thereafter, the processing device may assign asingle field professional to provide the on-site services at firstlocation 4506 and at the second location 4510 on the (same) particularday. In one embodiment, the processing device may determine that thesecond location is in proximity to the first location when an estimateddriving duration between the second location and the first location isless than 60 minutes, less than 45 minutes, less than 30 minutes, orless than 15 minutes. In another embodiment, the processing device maydetermine that the on-site service for the connected device can bescheduled on the (same) particular day by comparing the estimateddriving duration to a threshold associated with the urgency level. Forexample, for urgent services the threshold may be 2 hours, for lessurgent services the threshold may be 1 hour. The term “threshold” isused here to denote a reference value, a level, a point, or a range ofvalues, for which, when the driving duration is below it, the processingdevice may allow the on-site service for the connected device to bescheduled on the certain date.

With reference to the example illustrated in FIG. 45, prior toscheduling the on-site service for the connected device at location4510, the processing device may confirm that Bruce and Chuck have theskills required to complete the on-site service. In this example bothBruce and Chuck have the required skills. Therefore, the processingdevice may check if Bruce and Chuck have time availability in theirdaily schedule. Assuming Bruce's schedule is full, the processing devicemay schedule the on-site service associated with the second request toChuck on June 9^(th). In some cases, the processing device may determinethat the connected device in location 4510 may be accessed without thepresence of its owner. If this is the case, the processing device mayuse real-time data from field professionals to reschedule the on-siteservice for the connected device. For example, on June 8 the processingdevice may reschedule the on-site service after learning that Bruce hadcompleted the on-site service in location 4504 after 20 minutes insteadof the estimated 55 minutes. The processing device may identify a windowof opportunity for Bruce to complete the on-site service for theconnected device in location 4510 and reschedule the on-site serviceassociated with the second request to Bruce on June 8^(th).

FIG. 46 is a flowchart of an example method 4600 for scheduling tasks tofield professionals executed by a processing device of system 100,according to embodiments of the present disclosure. For purposes ofillustration, in the following description reference is made to certaincomponents of system 100. It will be appreciated, however, that otherimplementations are possible and that other components may be utilizedto implement the exemplary method. It will also be readily appreciatedthat the illustrated method can be altered to modify the order of steps,delete steps, or further include additional steps.

At step 4602, a processing device (e.g., processing device 202) receivesa first request for an on-site service, wherein the first requestincludes information identifying a location associated with a customer.In one embodiment, the first request for the on-site service may bereceived directly from a human customer. In another embodiment, thefirst request for the on-site service may be received from a connecteddevice associated with a human customer.

At step 4604, the processing device schedules a task associated with thefirst request to be performed by a field professional on a firstscheduled date. The term “scheduled date” is meant to include dateand/or time, as appropriate. In one example, the scheduled date mayinclude a time range (e.g., between 1:00 PM to 5:00 PM). In anotherexample, the scheduled date may include an exact time (e.g., 11:15 AM).In one embodiment, the processing device may schedule the taskassociated with the first request on the first scheduled date based onthe information identifying the location associated with the customer.For example, when the location associated with the customer is next to apublic school, the processing device may avoid scheduling services atthe times when school ends. In addition, the location may providedetails for selecting the most fitting field professional. For example,one of the field professionals may have more experience completingon-site services in the type housings found at the location identifiedin the request. In another embodiment, the processing device maydetermine the first scheduled date based on an availability (and/orpredicated availability) of the human customer. For example, theprocessing device may retrieve information indicative of an availabilityof the human customer at the location for accepting the on-site service(e.g., from social network, online source, past answers), and propose atleast one time slot for providing the on-site service based on retrievedinformation.

At step 4606, the processing device receives a second request from aconnected device for an on-site service. The request may include a widerange of data formats, such as messages, reports, measurements, andother feedback generated by the connected device. In one embodiment, therequest from the connected device may include a data stream with valuesof a plurality of parameters associated with a plurality ofsoftware-driven components of the connected device or of a devicemonitored by the connected device. In this embodiment, the processingdevice may process the data stream to determine that the connecteddevice is in need of an on-site service. In another embodiment, therequest from the connected device may include identification of acondition of a software-driven component that requires an on-siteservice. The second request may be associated with a repair service or amaintenance service for the connected device. For example, the datastream from the connected device may be indicative of a failure of oneof the components of the connected device. Alternatively, the secondrequest may be associated with a repair service or a maintenance servicefor a device monitored by the connected device. For example, a singleconnected device may monitor a plurality of devices and the data steamfrom the connected device may be indicative of a failure of one of themonitored devices.

Consistent with the present disclosure, the second request may have anassociated urgency level determined by information received from theconnected device. In one embodiment, the connected device may determinethe urgency level by itself and may include the associated urgency levelin the request for on-site service. In another embodiment, theprocessing device may determine the urgency level from the informationreceived from the connected device. For example, the request from theconnected device may include information indicative of a condition of atleast one component (or a group of components) of the connected deviceor a condition of at least one device (or a group of devices) monitoredby the connected device. In addition, the processing device maydetermine the urgency level from the information received from theconnected device and historical data associated with the connecteddevice. For example, database 154 may include historical data associatedwith a plurality of connected devices, such as past status updates; theprocessing device may use the historical data to predict an upcomingmalfunction of one of the components of the connected device or of adevice monitored by the connected device. In this example, thedetermined urgency level corresponds to the predicated upcomingmalfunction.

In some embodiments, the processing device may determine a time periodthat corresponds with the associated urgency level of the on-siteservice for the connected device. For example, assuming the urgencylevel is a value on a scale of one to ten where “ten” is very urgent and“one” is not urgent, a length of time period may be inverselyproportionate to the urgency level, e.g., when the urgency level is“three” the time period may be thirty days and when the urgency level is“nine” the time period may be two days. Thus, as urgency level increasesthe time period may decrease. Furthermore, the processing device mayalso determine the time period based on the urgency level and based onthe type of the connected device. The type of the connected device maybe associated with the manufacture of the connected device, the owner ofthe connected device, the category of the connected device, the locationof the connected device, and the pending tasks of the connected device.For example, a connected device of a municipality may receive a higherpriority than a connected device of an individual. In other words, twoconnected devices with a same urgency level may be assigned with twodifferent time periods. In another embodiment, the processing device mayreceive one or more updates associated with the urgency level from theconnected device, and may change the time period based on the receivedupdates. For example, the updates from a connected device may indicate achange in status of at least one component of the connected device (orchange in status of at least one device monitored by the connecteddevice), which may require rescheduling the on-site service to anearlier date. Therefore, after receiving the updates, the processingdevice may determine again the urgency level and/or the time period. Inone embodiment, the processing device may confirm that the scheduleddate for the on-site service associated with the connected device iswithin the determined time period (e.g., within a second time perioddetermined based on the received updates).

At step 4608, the processing device schedules a task associated with thesecond request to be performed on a second scheduled date based on theassociated urgency level. The second scheduled date may be before thefirst scheduled date, after the first scheduled date, or on the samedate. In some embodiments, the processing device may schedule the taskassociated with the second request to a field professional other thanthe field professional scheduled for the task associated with the firstrequest. Alternatively, the processing device may assign the same fieldprofessional to provide on-site services associated with the first andsecond requests. In some instances, a single field professional may beassigned where the first request is from a human customer and the secondrequest is from a connected device. For example, when a fieldprofessional completes a first task associated with a human customerearlier than estimated and he/she has time before departing to a nexttask, the processing device may assign the field professional a secondtask associated with a connected device in its proximity (e.g., within10 minutes' drive). In additional embodiments, the processing device maydetermine accessibility of the connected device and schedule the taskassociated with the second request based on the accessibility of theconnected device. The accessibility of the connected device may be fortime periods in which the field professional can complete the on-siteservice to the connected device. For example, when the connected deviceis located outdoors, the task can be scheduled as early as 6:00 AM. Butwhen the connected device is located within a company premises, the taskcan be scheduled only during the opening hours.

At step 4610, the processing device receives confirmation that the taskassociated with the first request and the task associated with thesecond request have been completed. A confirmation in this context mayrefer to a message sent to the processing device after an on-siteservice is completed. In some non-limiting examples, the confirmationmay be received from the at least one field professional assigned to thetask associated with the first request and to the task associated withthe second request. Alternatively, the confirmation may be received fromthe connected device and/or the customer.

O. Scheduling Parts Delivery

Some on-site services provided by field professionals require specificparts for completion. Every so often, while in the field, fieldprofessionals discover that they need a certain part to complete anon-site service. The following disclosure describes methods and systemsfor scheduling delivery of parts to field professionals currently in thefield. In the context of this disclosure, “parts” may refer to any typeof component or hardware utilized in connection with an on-site serviceby a field professional. In a first embodiment, the delivered parts mayinclude replacement parts; for example, technicians scheduled to repairelectrical devices may require different components for repairing thedevices, such as, cables, fuses, switches, circuits, and more. In asecond embodiment, the delivered parts may include disposables; forexample, a medical service provider scheduled to visit patients may usea variety of disposables parts, such as syringes, needles, sutures,staples, packaging, tubing, catheters, medical gloves, gowns, masks,adhesives, and more. In a third embodiment, the delivered parts mayinclude tools; for example, some on-site services require the fieldprofessionals to use certain tools not part of the default inventory,such as a driller for reinforced concrete or a dialysis machine. Fieldprofessionals assigned to provide on-site services may start their daywith an inventory of parts that is configured to enable completion ofthe tasks scheduled for that day. Yet, it is not uncommon that duringthe day some parts are unexpectedly needed. In one case, a fieldprofessional arrives at a location associated with a scheduled task andlearns that a specific part not found in her inventory (e.g., a tool) isneeded to complete the on-site service. In another case, a fieldprofessional may unexpectedly be required to use parts in one task(e.g., replacement parts or disposables) meaning that the fieldprofessional may not be able to compete a later task.

FIG. 47 is a schematic illustration to explain a field professional'suse of parts throughout a workday. FIG. 47 depicts a daily schedule 4700that shows the times and durations of each of tasks A, B, C, and Dassigned to a field professional by server 152 between 8:00 and 16:00 ofa workday. In the illustrated example the field professional may be acomputer technician and each task in daily schedule 4700 includes anindication of the one or more parts expected to be used in each task. Inone embodiment, server 152 may predict which parts the fieldprofessional will need to use in each task based on details derivablefrom a request for the on-site service. For example, server 152 maypredict that task A would require replacing a motherboard; task B wouldrequire replacing a hard disk drive; task C would require replacing aGraphics Processing Unit (GPU); and task D would require replacing adifferent motherboard. A person skilled in the art would recognize thatthe above example is simplified, and an actual repair service mayinvolve substantially more parts (e.g., more replacement parts, specifictools, etc.).

Based on the prediction of parts that the field professional will needto use in each task, an inventory of parts 4710 may be assigned to thefield professional. In the illustrated example, inventory 4710 includesGPU 4712, motherboards 4714A, 4714B, and 4716, and hard disk drive 4718Aand 4718B. As shown in daily schedule 4700, the field professional hadto unexpectedly use GPU 4712 for completing task A, although GPU 4712was intended to be used in task C. In order to be able to complete taskC, server 152 may schedule a delivery of GPU 4720 to the fieldprofessional. The different alternatives for delivering GPU 4720 to thefield professional are described below with reference to FIG. 48.

FIG. 48 is a schematic map that illustrates possible parts deliverypoints along a travel path of a field professional. With reference toFIG. 47, field professional 4800 may be assigned to tasks A, B, C, D forproviding technical service at locations A, B, C, and D. The route offield professional 4800 is schematically illustrated in a solid line andthe different parts-delivery options are illustrated in dashed lines.Consistent with the present disclosure, server 152 may determine thatfield professional 4800 needs an additional part (e.g., a GPU) notcurrently in its assigned inventory to complete one of the scheduledtasks. For example, when field professional 4800 completed the on-siteservice associated task A, server 152 may receive in real-time anindication of the updated inventory of parts currently available tofield professional 4800. From the received indication, server 152 maydetermine that in completing task A field professional 4800 unexpectedlyused a certain part (e.g., GPU 4712) needed to complete task C.Accordingly, server 152 may schedule a task for delivery of the at leastone additional part (e.g., GPU 4720) to field professional 4800. In theillustrated example, the at least one additional part can be deliveredfrom two storage locations; namely, the first storage facility and thesecond storage facility.

Consistent with embodiments of the present disclosure, server 152 maydetermine a location for delivering at least one part to the fieldprofessional based on locations of scheduled tasks in a daily scheduleof the field professional and/or based on a current location of fieldprofessional 4800 determined from a GPS receiver integrated withcommunication devices 180A. In addition, the determined location mayinclude a location between a current location of field professional 4800and a location of the task where the part is needed. For example, server152 may determine that the part needed for task C may be delivered tolocation A (option 4802), to a point between location A and location B(option 4804), or to location B (option 4806). In one embodiment, server152 may instruct field professional 4800 to wait before departing to anext task when the at least one part is scheduled to be delivered to thefield professional at the location associated with the current task. Forexample, with regards to option 4806, server 152 may instruct fieldprofessional 4800 to wait at location B before departing to location C.

In some cases, server 152 may select which storage facility will providethe at least one additional part to field professional 4800. Thedetermination may be based on the current location of field professional4800, the traffic conditions (current and predicted), the partsinventory in each storage facility, and other scheduling costsassociated with the part delivery. For example, server 152 may determinethat the at least one additional part (e.g. GPU 4720) will be deliveredto location C from the second storage facility (option 4808) based ontraffic conditions. In one embodiment, server 152 may also identifyanother field professional has the at least one additional part (e.g.GPU 4720) currently available in his/her inventory of parts, andorganize a meet-up between the two field professionals. For example, afield professional 4810 may receive a task of meeting with fieldprofessional 4800 at a point between location B and location C (option4812). In an alternative embodiment, the task for delivering the atleast one additional part to field professional 4800 may includeinstructing field professional 4800 to purchase the least one additionalpart (e.g. GPU 4720) at a specific store that may be located next tofield professional 4800 (option 4814).

FIG. 49A is a flowchart of an example method 4900 for scheduling partsdelivery executed by a processing device of system 100, according toembodiments of the present disclosure. For purposes of illustration, inthe following description, reference is made to certain components ofsystem 100. It will be appreciated, however, that other implementationsare possible and that other components may be utilized to implement theexemplary method. It will also be readily appreciated that theillustrated method can be altered to modify the order of steps, deletesteps, or further include additional steps.

At step 4902, a processing device (e.g., processing device 202) mayreceive a set of requests for on-site services. The on-site servicesassociated with at least some of the requests require parts. Asmentioned above, the term “parts” may refer to any type hardware beingutilized during an on-site service by a field professional. For example,the parts may include replacement parts, disposables, or tools. At step4904, the processing device may schedule a set of tasks corresponding tothe set of requests for a field professional. The scheduling of thetasks may be based on the skills of the field professional and theexpected availability of the parts. In one embodiment, the processingdevice may determine the expected availability of parts based on dataassociated with previously scheduled tasks and offer time slots forusers for the on-site services based on the expected availability of theparts. In one example, where the parts include a certain component of anelectric device, the processing device may predict that the certaincomponent may be out-of-stock by Tuesday. Accordingly, the processingdevice may offer a user requesting the service time slots on Wednesday.In another example, where the parts include a certain tool, theprocessing device may determine that the certain tool is alreadyscheduled to be used on Tuesday at a location far from the locationassociated with a current request. Accordingly, the processing devicemay offer a user requesting the service time slots on Wednesday.

At step 4906, the processing device may determine a set of parts thatthe field professional is likely to require to complete the set oftasks. In one embodiment, the processing device may determine whichparts the field professional would need for completion of the set oftasks based on details of the requests for the on-site services.Consistent with the present disclosure, the processing device maydetermine information indicative of the types of parts required tocomplete the task from the requests for the on-site service. Theinformation may include the type of task, the location of the task, theweather predicted at the time of the task, and more. For example,installing Internet connection may require different replacement partswhen the location is a private property or an apartment house. Inanother embodiment, the processing device may determine which parts thefield professional would need for completion of the set of tasks basedon historical data indicative of the previous parts used in taskssimilar to the scheduled set of tasks. For example, a certainneighborhood may experience poor infrastructure and completing someservices in that neighborhood requires certain parts.

In another embodiment, the processing device may determine the set ofparts that the field professional is likely to require using atask-to-parts database. The task-to-parts database (e.g., part ofdatabase 154) may correlate different types of tasks with one or moreparts. In one example, the data structure of records in thetask-to-parts database may include a set of tuples. Some tuples maycontain information related to tasks and any specific work related toperforming each task, and some tuples may contain information related toany components or parts related to each specific work item. In this way,the data structure can be accessed to quickly identify the parts foreach task to support identification of parts not currently on hand in afield professional's available inventory when on-site. In yet anotherembodiment, the processing device may determine the set of parts thatthe field professional is likely to require using a customer databasethat may be stored locally by the customer or stored in database 154.The processing device may access the customer database to determine ifthe customer has some parts that the field professional may need duringthe on-site service. For example, the processing device may determinethat for a certain patient the field professional does not need to bringa dialysis machine because the patient has his own dialysis machine.

At step 4908, the processing device may determine that the fieldprofessional needs an additional part not currently in the fieldprofessional's assigned inventory to complete the set of tasks. Thefield professional's assigned inventory or individual inventory refersto a group of parts readily available to a field professional while thefield professional is traveling between different locations associatedwith different tasks. In one embodiment, more applicable when the partsare disposables or replacement parts, the processing device may receivein real time an indication of an inventory of parts currently availableto the field professional. The inventory of parts may be updated aftereach task in a daily schedule of tasks is completed. For example, theprocessing device may determine the individual inventory from updatesfrom the field professional or from sensors (e.g., weight sensors, imagesensors) that monitor the inventory of parts. In another embodiment, theprocessing device may receive from the field professional, while thefield professional is at a location associated with a current task, arequest for a specific part needed for completion of the current task.Upon receiving the request, the processing device may schedule a taskfor delivery in the field of the requested part to the locationassociated with a current task to enable the field professional tocomplete the current task. For example, when the field professional is amedical professional, a nurse may determine that a certain tool (e.g.,an inhalator) is needed during a check-up with a patient.

At step 4910, the processing device may schedule a task for delivery inthe field of the at least one additional part to the field professional.In one embodiment, the processing device may schedule the delivery taskto ensure timely arrival of the additional part at a location associatedwith the task determined to require the additional part to complete thattask. As illustrated in FIG. 48, the additional part may be deliveredbefore or after the field professional arrives at the locationassociated with the task determined to require the additional tocomplete that task. In another embodiment also illustrated in FIG. 48,the processing device may schedule the delivery task of the at least oneadditional part to arrive at a location along a route assigned to thefield professional. Consistent with the present disclosure, thescheduling delivery of the at least one additional part may includebooking or assigning an autonomous vehicle (e.g., a drone or anautonomous car) for delivering the at least one additional part. Theautonomous vehicle may be part of a transportation service, such asUber™, Lyft™ and Via™.

FIG. 49B depicts a related method 4950 for scheduling parts deliveryused by a processing device of system 100, according to embodiments ofthe present disclosure. For purposes of illustration, in the followingdescription reference is made to certain components of system 100. Itwill be appreciated, however, that other implementations are possibleand that other components may be utilized to implement the exemplarymethod. It will also be readily appreciated that the illustrated methodcan be altered to modify the order of steps, delete steps, or furtherinclude additional steps.

At step 4952, a processing device (e.g., processing device 202) mayreceive a set of requests for on-site services, wherein the on-siteservices of at least some of the requests require parts. At step 4954,the processing device may schedule a set of tasks corresponding to theset of requests for a field professional. In one embodiment, a taskassociated with a certain request may be associated with a set of partsneeded for completion of the set of tasks. The set of parts may includeparts from a first type of parts and a second type of parts (e.g.,replacement parts and tools). In one example the field professional maybe a technician and the set of parts may include communication hardware(e.g., cables, switches) and a concrete drilling tool (e.g., concretedemolition hammer). The system may cause a delivery of either the firsttype of parts, the second type of parts, or both. In another example,the field professional may be a nurse and the set of parts may include adisposable medical product (e.g., drugs, stoma bags) and a medicaldevice (e.g., a dialysis machine).

At step 4956, the processing device may provide data indicative ofexpected parts that the field professional would need for completion ofthe set of tasks. The data indicative of expected parts may include atleast one list of parts; for example, a list of tools needed forcompletion of the set of tasks, a list of replacement parts needed forcompletion of the set of tasks, and a list of disposables needed forcompletion of the set of tasks. In some cases, the processor maydetermine the data indicative of expected parts based on historical dataabout parts used in previous tasks similar to the scheduled set oftasks. In one embodiment, the data indicative of expected parts may beassociated with tasks for that day and may be provided before the fieldprofessional departs to the field.

At step 4958, the processing device may receive from the fieldprofessional, while the field professional is at a location associatedwith a current task, a request for at least one additional part. Therequest may be indicative of a specific part needed for completion ofthe current task or a specific part needed for completion of a futuretask. Consistent with the present disclosure, the request may beinitiated by the field professional or by an electronic deviceassociated with the field professional (e.g., communication devices180A). In some embodiments, the request may include an explicitidentification of the at least one additional part or data indicative ofthe current status of the individual inventory of the fieldprofessional. For example, the request may include data indicative ofparts that were unexpectedly used in at least one earlier task. Inanother embodiment, the processing device may determine that the atleast one additional part is associated with a future task and it cannotbe delivered in time to the field professional. Accordingly, theprocessing device may reassign that future task to another fieldprofessional having the at least one additional part. In some cases,even if a part may be delivered to the field professional before thefuture task, it may still be beneficial to reassign the future task toanother field professional instead of scheduling the part delivery. Theprocessing device may decide whether to schedule a delivery of the atleast one additional part or reassign the future delivery based onreal-time data, such as other field professionals current location andtheir pending tasks.

At step 4960, the processing device may schedule a task for delivery inthe field of the requested at least one additional part to the fieldprofessional. In one embodiment the at least one additional part can bedelivered from a plurality of storage locations (e.g., the first andsecond storage facilities depicted by FIG. 48). The processing devicemay select one of the plurality of storage locations for providing theat least one additional part. In addition, the selection of the storagelocation for providing the at least one additional part may be based ona predicted demand for parts and/or real-time information about thecurrent demand for said parts. For example, the first storage facilitymay be closer to a current location of the field professional and haseight pieces of the required parts, whereas the second storage facilityhas only five pieces. Nevertheless, the processing device may select thesecond storage facility because all the eight pieces from the firststorage facility are predicted to be used tomorrow, and the next supplyof the pieces to the first storage facility is scheduled for the nextweek.

The foregoing description has been presented for purposes ofillustration. It is not exhaustive and is not limited to the preciseforms or embodiments disclosed. Modifications and adaptations will beapparent to those skilled in the art from consideration of thespecification and practice of the disclosed embodiments. Additionally,although aspects of the disclosed embodiments are described as beingstored in memory, one skilled in the art will appreciate that theseaspects can also be stored on other types of computer readable media,such as secondary storage devices, for example, hard disks or CD ROM, orother forms of RAM or ROM, USB media, DVD, Blu-ray, or other opticaldrive media.

Computer programs based on the written description and disclosed methodsare within the skill of an experienced developer. The various programsor program modules can be created using any of the techniques known toone skilled in the art or can be designed in connection with existingsoftware. For example, program sections or program modules can bedesigned in or by means of .Net Framework, .Net Compact Framework (andrelated languages, such as Visual Basic, C, etc.), Java, C++,Objective-C, HTML, HTML/AJAX combinations, XML, or HTML with includedJava applets.

Moreover, while illustrative embodiments have been described herein, thescope of any and all embodiments having equivalent elements,modifications, omissions, combinations (e.g., of aspects across variousembodiments), adaptations and/or alterations as would be appreciated bythose skilled in the art based on the present disclosure. Thelimitations in the claims are to be interpreted broadly based on thelanguage employed in the claims and not limited to examples described inthe present specification or during the prosecution of the application.The examples are to be construed as non-exclusive. Furthermore, thesteps of the disclosed methods may be modified in any manner, includingby reordering steps and/or inserting or deleting steps. It is intended,therefore, that the specification and examples be considered asillustrative only, with a true scope and spirit being indicated by thefollowing claims and their full scope of equivalents.

What is claimed is:
 1. A system for scheduling tasks to fieldprofessionals, the system comprising: a network interface; and at leastone processor connectable to the network interface, the at least oneprocessor is configured to: receive a set of requests reflecting demandfor on-site services, wherein the set of requests is associated with anumber of task types; receive availability data indicative of anavailability of a plurality of field professionals to perform on-siteservices; receive skills data indicative of capabilities of each of theplurality of field professionals with respect to the task types; obtainat least one desired scheduling weight for the number of task types;generate a schedule for the plurality of field professionals based onthe demand for on-site services, the availability data, and the skillsdata; and wherein generating the schedule for the plurality of fieldprofessionals comprises including a first task in the schedule when thefirst task conforms with the at least one desired scheduling weight andexcluding a second task from the schedule when the second task does notconform with the at least one desired scheduling weight.
 2. The systemof claim 1, wherein the number of task types includes different types ofservice.
 3. The system of claim 1, wherein the number of task typesincludes different types of products.
 4. The system of claim 1, whereinthe at least one processor is configured to determine the availabilitydata from inputs from the plurality of field professionals associatedwith a period time.
 5. The system of claim 1, wherein the at least oneprocessor is configured to determine the availability data from personalrecords of the plurality of field professionals.
 6. The system of claim1, wherein the at least one processor is configured to determine theskills data from personal records of the plurality of fieldprofessionals.
 7. The system of claim 1, wherein the at least oneprocessor is configured to determine the skills data based on rankingassociated with customers' feedback of the plurality of fieldprofessionals.
 8. The system of claim 1, wherein obtaining the at leastone desired scheduling weight includes receiving an input indicative ofthe at least one desired scheduling weight.
 9. The system of claim 1,wherein obtaining the at least one desired scheduling weight includesusing artificial intelligence (AI) to determine the at least one desiredscheduling weight for increasing throughput.
 10. The system of claim 1,wherein the at least one processor is further configured to scheduletasks that do not conform with the desired scheduling weight when adaily schedule of the plurality of field professionals is not full. 11.The system of claim 1, wherein the at least one processor is furtherconfigured to provide, using the network interface, to a fieldtechnician information reflecting an assignment of the first task. 12.The system of claim 11, wherein the information reflecting theassignment of the first task includes details about a customerassociated with the first task.
 13. The system of claim 11, wherein theinformation reflecting the assignment of the first task includesdescription of the first task.
 14. The system of claim 11, wherein theinformation reflecting the assignment of the first task includesdirectional instructions to an identified location associated with thefirst task.
 15. The system of claim 1, wherein the at least oneprocessor is configured to determine scheduling policies based onavailable resources and wherein generating the schedule is based on thescheduling policies.
 16. A method for scheduling tasks to fieldprofessionals, the system comprising: receiving a set of requestsreflecting demand for on-site services, wherein the set of requests isassociated with a number of task types; receiving availability dataindicative of an availability of a plurality of field professionals toperform on-site services; receiving skills data indicative ofcapabilities of each of the plurality of field professionals withrespect to the task types; obtaining at least one desired schedulingweight for the number of task types; generating a schedule for theplurality of field professionals based on the demand for on-siteservices, the availability data, and the skills data; and whereingenerating the schedule for the plurality of field professionalscomprises including a first task in the schedule when the first taskconforms with the at least one desired scheduling weight and excluding asecond task from the schedule when the second task does not conform withthe at least one desired scheduling weight.
 17. The method of claim 16,wherein the method further includes receiving historical data associatedwith past demand for the task types, and wherein generating the schedulefor the plurality of field professionals is further based on aprediction of demand associated with the received historical data. 18.The method of claim 16, wherein the method further includes receivingenvironmental data indicative of future events that affect completion oftasks, and wherein generating the schedule for the plurality of fieldprofessionals is further based on the environmental data.
 19. The methodof claim 16, wherein a first request associated with the first task isreceived after a second request associated with the second task.
 20. Themethod of claim 19, wherein the first task is associated with a firstscheduling weight higher than a second scheduling weight associated withthe second task.